Handbuch Projektmanagement Agil Klassisch Hybrid

#projektmanagement #handbuch #buch #pm

Handbuch Projektmanagement – Agil – Klassisch – Hybrid

Jürg Kuster, Christian Bachmann, Eugen Huber, Mike Hubmann, Robert Lippmann, Emil Schneider, Patrick Schneider, Urs Witschi, Roger Wüst

4., vollständig überarbeitete und erweiterte Auflage, Springer Gabler 2018

---

Handbuch

Projektmanagement

Jürg Kuster · Christian Bachmann

Eugen Huber · Mike Hubmann

Robert Lippmann · Emil Schneider

Patrick Schneider · Urs Witschi

Roger Wüst

Agil – Klassisch – Hybrid

4. Auflage

Handbuch Projektmanagement

Jürg Kuster Christian Bachmann

Eugen Huber Mike Hubmann

Robert Lippmann Emil Schneider

Patrick Schneider Urs Witschi Roger Wüst

Handbuch

Projektmanagement

Agil – Klassisch – Hybrid

4., vollständig überarbeitete und erweiterte Auflage

Jürg Kuster

Winterthur, Schweiz

Christian Bachmann

Bäretswil, Schweiz

Eugen Huber

Parpan, Schweiz

Mike Hubmann

Liebefeld, Schweiz

Robert Lippmann

Männedorf, Schweiz

Emil Schneider

Warth, Schweiz

Patrick Schneider

Nussbaumen TG, Schweiz

Urs Witschi

Ennetbaden, Schweiz

Roger Wüst

Dänikon, Schweiz

ISBN 978-3-662-57877-3

ISBN 978-3-662-57878-0 (eBook)

https://doi.org/10.1007/978-3-662-57878-0

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliograﬁe; detaillier-

te bibliograﬁsche Daten sind im Internet über http://dnb.d-nb.de abrufbar.

Springer Gabler

Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht ausdrücklich

vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlags. Das gilt insbesondere

für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverﬁlmungen und die Einspeicherung und Verar-

beitung in elektronischen Systemen.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt

auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen-

und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.

Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informationen in diesem

Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind. Weder der Verlag noch die Autoren oder

die Herausgeber übernehmen, ausdrücklich oder implizit, Gewähr für den Inhalt des Werkes, etwaige Fehler

oder Äußerungen. Der Verlag bleibt im Hinblick auf geograﬁsche Zuordnungen und Gebietsbezeichnungen in

veröffentlichten Karten und Institutionsadressen neutral.

Lektorat: Stefanie Winter

Zeichnungen: Agentur Aufwind GmbH, CH-7000 Chur, Corina Rüegg und Reto Sommerau

Springer Gabler ist ein Imprint der eingetragenen Gesellschaft Springer-Verlag GmbH, DE und ist ein Teil von

Springer Nature.

Die Anschrift der Gesellschaft ist: Heidelberger Platz 3, 14197 Berlin, Germany

Vorwort zur vierten Auflage

Die vorliegende vierte, vollständig überarbeitete Auﬂage des „Handbuches Projekt-

management“ basiert auf den Grundlagen des bisherigen Standardwerkes. Sie behandelt

eine Vielzahl neuer oder aktualisierter Themen. Das Handbuch enthält Erkenntnisse und

Empfehlungen aus unserer Praxis als Projektleiter und Projekt-Coaches sowie aus unserer

Lehrtätigkeit im Projektmanagement. Besonders freut uns, dass dieses Werk nicht nur ei-

ne Summe von Beiträgen aus verschiedenen Federn ist, sondern dass wir uns als Team in

ungezählten Stunden ausgetauscht und die Inhalte gemeinsam strukturiert und entwickelt

haben.

Seit Erscheinen der ersten Auﬂage im Jahr 2008 haben wir für rund 8000 Teilnehmer

in mehr als 200 Organisationen in der Schweiz, in Deutschland und Österreich sowohl

öffentliche wie auch ﬁrmenspeziﬁsche Trainings zum Projektmanagement durchgeführt

oder Entwicklungsarbeit zur Förderung der Projektmanagement-Kompetenz in diesen Or-

ganisationen geleistet. Man darf also mit Fug und Recht behaupten, dass das vorliegende

Werk sowohl die heutige als auch die künftige Praxis des Projektmanagements widerspie-

gelt.

Einer der großen Trends der letzten Jahre ist, dass nicht nur bewährte Führungsstruk-

turen, -konzepte und -prozesse gefragt sind, sondern vermehrt temporäre Organisationen

eingesetzt werden, um rascher und ﬂexibler agieren zu können. Die hierarchischen Füh-

rungsbeziehungen werden abgelöst durch laterale Systeme mit ﬂexiblen Rollenmodellen

und stark lösungsorientierten Zusammenarbeitsformen. Projektmanagement ist von die-

ser Entwicklung stark betroffen. Wir haben diese Tatsache mit einer deutlich erkennba-

ren Leserführung umgesetzt. Diese unterscheidet nicht nur zwischen der agilen und der

klassischen Projektführung, sondern vertieft auch die für die Zukunft wahrscheinlichste

Methode, die hybride Projektabwicklung. Diese ermöglicht eine situations- und phasen-

speziﬁsche Kombination beider Modelle.

Eine weitere Neuheit sind reale Projektdokumente, welche wir als Praxisbeispiele in

dieses Buch eingefügt haben. Dafür danken wir dem Transportunternehmen BLS, na-

mentlich Daniel Hofer, Irina Schneider, Daniel Leuenberger und Marc Zesiger sowie

dem Schweizer Hersteller von Präzisionsgeräten für die chemische Analytik Metrohm,

namentlich Patrick Hunziker, Christian Feuerlein, Michael Edelmann und Karolina Bruck-

müller.

Vorwort zur vierten Auflage

Die Visualisierung der Inhalte haben wir für diese Auﬂage in professionelle Hände

gegeben. Wir danken Corina Rüegg und Reto Sommerau von der Kommunikationsagentur

Aufwind in Chur, dass sie mit großer Konsequenz die Abbildungen in diesem Buch auf

überzeugende Einfachheit und klare Aussagekraft getrimmt haben.

Struktur dieses Buches

Verschiedene Strukturelemente vereinfachen die Anwendung dieses umfassenden Werkes

in der Praxis. Der Projektmanagement-Kompass dient als detaillierte Orientierungshilfe

für die Projektabwicklung und präsentiert zwei unterschiedliche Vorgehensmodelle für

agil und klassisch geführte Projekte.

Der Erfolg von komplexen, interdisziplinären Vorhaben setzt gerade beim Projektma-

nager zunehmend breit gefächerte Kompetenzen voraus. Deshalb stellen wir die methodi-

schen Grundlagen in Bezug zum Menschen, der im Team das Projekt umsetzt. Die Ebenen

„Methodik“, „Mensch“ und „Team“ stehen in einer Wechselwirkung zueinander. Darum

ist der Buchinhalt in vier Kapitel gegliedert:

1. Übersicht Projektmanagement im Überblick und im Führungskontext

2. Methodik Modelle und Arbeitsmethodik zur Abwicklung von agilen und klassischen

Projekten

3. Mensch Wesentliche Merkmale des Menschen als Gestalter von Projekten

4. Team Aspekte der erfolgreichen Zusammenarbeit in Teams

Das vorliegende Werk wurde auch mit Blick auf die Zertiﬁzierung nach IPMA ver-

fasst und bietet in Kap. 5 eine umfassende Referenztabelle zu sämtlichen Kompetenzele-

menten der Individual Competence Baseline von IPMA® (ICB4).

Wir wünschen Ihnen viele neue Einsichten bei der Lektüre und den gewünschten Erfolg

in Ihren zukünftigen Projekten.

Im November 2018

Jürg Kuster

Christian Bachmann

Eugen Huber

Mike Hubmann

Robert Lippmann

Emil Schneider

Patrick Schneider

Urs Witschi

Roger Wüst

Vorwort zur vierten Auflage

VII

Auf einen Blick

Einleitung .......................................................................................................................................1

1.1

Projektmanagement, wozu? ..................................................................................................1

1.2

Was sind Projekte? ...............................................................................................................3

1.3

Was ist Projektmanagement? .............................................................................................12

1.4

Vorgehensmodelle in Projekten .........................................................................................18

1.5

Projekte basieren auf Teamarbeit .......................................................................................38

1.6

Projekte sind soziale Systeme ............................................................................................41

1.7

Vielseitigkeit und Kreativität .............................................................................................46

1.8

Standards und Zertifizierungsmodelle im Projektmanagement .........................................51

1.9

Projektportfolio-, Multiprojekt- und Programmmanagement ............................................58

Methodik ......................................................................................................................................61

2.1

Einführung ..........................................................................................................................61

2.2

Phase Projektbeauftragung .................................................................................................69

2.3

Phase Initialisierung ...........................................................................................................74

2.4

Phase Konzept ..................................................................................................................159

2.5

Phase Realisierung............................................................................................................195

2.6

Phase Einführung..............................................................................................................229

2.7

Projektportfolio- und Programmmanagement ..................................................................239

2.8

Lösungsfindung ................................................................................................................255

2.9

Beschaffung ......................................................................................................................268

Mensch .......................................................................................................................................275

3.1

Kompetenzmodell.............................................................................................................275

3.2

Bedingungen für gute Leistung ........................................................................................276

3.3

Phänomen Mensch............................................................................................................278

3.4

Persönliche Kultur und Werte ..........................................................................................293

3.5

Stress und Veränderung ....................................................................................................295

3.6

Flow ..................................................................................................................................302

3.7

Motivation und Sinn .........................................................................................................304

3.8

Selbstmanagement ............................................................................................................308

3.9

Persönliche Kommunikation ............................................................................................318

3.10

Persönliche Weiterentwicklung ........................................................................................335

Team ..........................................................................................................................................347

4.1

Zusammenarbeit und Führung ..........................................................................................347

4.2

Dynamik in Teams ...........................................................................................................403

4.3

Verhandlungsführung .......................................................................................................409

4.4

Konfliktmanagement und Krisen .....................................................................................422

4.5

Veränderung und Widerstand ...........................................................................................476

4.6

Zum Schluss ... .................................................................................................................492

Referenzliste zur Individual Competence Baseline (ICB) der IPMA ........................................495

Inhaltsverzeichnis

Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1

Projektmanagement, wozu? . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2

Was sind Projekte? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2.1

Projektausprägungen . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2.2

Projektarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2.3

Projektwürdigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2.4

Klassiﬁzierung von Projekten . . . . . . . . . . . . . . . . . . . . . .

1.2.5

Entstehung von Projekten . . . . . . . . . . . . . . . . . . . . . . . . .

1.3

Was ist Projektmanagement? . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.1

Hierarchien im Projektmanagement . . . . . . . . . . . . . . . . . . .

1.3.2

Dimensionen im Projektmanagement . . . . . . . . . . . . . . . . . .

1.3.2.1 Kompetenzbereich Kontext (Perspective) . . . . . . . . . .

1.3.2.2 Kompetenzbereich Menschen (People) . . . . . . . . . . .

1.3.2.3 Kompetenzbereich Praktiken (Practice) . . . . . . . . . . .

1.3.3

Vorgehensprinzipien . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.3.1 Vom Groben zum Detail . . . . . . . . . . . . . . . . . . . .

1.3.3.2 Variantenbildung . . . . . . . . . . . . . . . . . . . . . . . . .

1.4

Vorgehensmodelle in Projekten . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.1

Agile Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.1.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.1.2 Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.2

Klassische Vorgehensweise: Phasenkonzept . . . . . . . . . . . . . .

1.4.2.1 Die Phase der Projektbeauftragung . . . . . . . . . . . . . .

1.4.2.2 Die Initialisierungsphase . . . . . . . . . . . . . . . . . . . .

1.4.2.3 Die Konzeptphase . . . . . . . . . . . . . . . . . . . . . . . .

1.4.2.4 Die Realisierungsphase . . . . . . . . . . . . . . . . . . . . .

1.4.2.5 Die Einführungsphase . . . . . . . . . . . . . . . . . . . . . .

1.4.2.6 Die Nutzung . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.3

Hybrides Projektmanagement . . . . . . . . . . . . . . . . . . . . . .

1.4.4

Change-Projekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.5

Weitere Vorgehensmodelle . . . . . . . . . . . . . . . . . . . . . . . .

Inhaltsverzeichnis

1.4.5.1 V-Modell

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.5.2 Simultaneous Engineering . . . . . . . . . . . . . . . . . . .

1.4.5.3 Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.5.4 Versionenkonzept . . . . . . . . . . . . . . . . . . . . . . . .

1.4.6

Wahl eines Vorgehensmodells – klassisch, agil oder hybrid? . . . .

1.5

Projekte basieren auf Teamarbeit . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.1

Inhalt: Arbeit im System

. . . . . . . . . . . . . . . . . . . . . . . . .

1.5.2

Organisation und Beziehung: Arbeit am System . . . . . . . . . . .

1.5.3

Wechselwirkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.6

Projekte sind soziale Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.6.1

Taylorismus in unseren Köpfen . . . . . . . . . . . . . . . . . . . . .

1.6.2

Menschen und Teams sind nicht-triviale Systeme . . . . . . . . . .

1.6.3

Systemischer Ansatz im Projektmanagement . . . . . . . . . . . . .

1.6.4

Mechanistisches und systemisches Weltbild . . . . . . . . . . . . . .

1.7

Vielseitigkeit und Kreativität . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.7.1

Vielseitigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.7.2

Kreativität als Überschuss von Aufmerksamkeit . . . . . . . . . . .

1.7.3

Wechselspiel zwischen Mensch, Feld und Domäne . . . . . . . . .

1.7.4

Rahmenbedingungen für Kreativität . . . . . . . . . . . . . . . . . .

1.8

Standards und Zertiﬁzierungsmodelle im Projektmanagement . . . . . . .

1.8.1

IPMA – International Project Management Association . . . . . .

1.8.2

PMI – Project Management Institute . . . . . . . . . . . . . . . . . .

1.8.3

PRINCE2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.8.4

HERMES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.8.5

Scrum Alliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.8.6

DIN 69901 und ISO 21500 . . . . . . . . . . . . . . . . . . . . . . . .

1.9

Projektportfolio-, Multiprojekt- und Programmmanagement . . . . . . . .

Literatur

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Methodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1

Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.1

Klassisch, agil und hybrid . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.2

Genauigkeit von Schätzungen . . . . . . . . . . . . . . . . . . . . . .

2.1.3

Praxisbeispiele

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2

Phase Projektbeauftragung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.1

Worauf kommt es in der Phase Beauftragung an? . . . . . . . . . .

2.2.2

Projektsteckbrief . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.3

Business Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.4

Projektantrag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.5

Checkliste Abschluss Projektbeauftragung . . . . . . . . . . . . . .

2.3

Phase Initialisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.1

Worauf kommt es in der Phase Initialisierung an? . . . . . . . . . .

Inhaltsverzeichnis

2.3.2

Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.2.1 Zielsetzung entlang der Projektphasen . . . . . . . . . . . .

2.3.2.2 Globalziel und Detailziele . . . . . . . . . . . . . . . . . . .

2.3.2.3 Systemziele und Vorgehensziele . . . . . . . . . . . . . . .

2.3.2.4 Kriterien für zweckmäßige Projektziele . . . . . . . . . . .

2.3.2.5 Mussziele und Wunschziele . . . . . . . . . . . . . . . . . .

2.3.3

Anforderungen/Requirements Engineering . . . . . . . . . . . . . .

2.3.3.1 Tätigkeiten des Requirements Engineering . . . . . . . . .

2.3.3.2 Arten von Anforderungen . . . . . . . . . . . . . . . . . . .

2.3.3.3 Kriterien für die Güte von Anforderungen und

Anforderungsdokumenten . . . . . . . . . . . . . . . . . . .

2.3.3.4 Priorisierung von Anforderungen . . . . . . . . . . . . . . .

2.3.4

Das magische Dreieck . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.5

Stakeholder-Management . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.5.1 Anspruchsgruppen managen . . . . . . . . . . . . . . . . . .

2.3.5.2 Stakeholder identiﬁzieren . . . . . . . . . . . . . . . . . . . .

2.3.5.3 Stakeholder analysieren . . . . . . . . . . . . . . . . . . . . .

2.3.5.4 Stakeholder bewerten . . . . . . . . . . . . . . . . . . . . . .

2.3.5.5 Stakeholder steuern . . . . . . . . . . . . . . . . . . . . . . .

2.3.6

Projektmarketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.7

Prüfung der Machbarkeit . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.8

Risikomanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

2.3.8.1 Die konkreten Schritte im Risikoprozess . . . . . . . . . . 100

2.3.8.2 Failure Mode and Effect Analysis (FMEA) . . . . . . . . . 106

2.3.9

Projektorganisation/Rollen/Gremien . . . . . . . . . . . . . . . . . . 108

2.3.9.1 Linie und Projekt: zwei unterschiedliche Welten

. . . . . 108

2.3.9.2 Die Rollen und Gremien . . . . . . . . . . . . . . . . . . . . 109

2.3.9.3 Kompetenzen und Führungsaufgaben in der

Projektorganisation . . . . . . . . . . . . . . . . . . . . . . . 110

2.3.9.4 Projektorganisation in der agilen Vorgehensweise . . . . . 110

2.3.9.5 Projektorganisation in der klassischen Vorgehensweise . 115

2.3.9.6 Projektorganisation in der hybriden Vorgehensweise . . . 118

2.3.9.7 Projektorganisation in Kundenprojekten . . . . . . . . . . . 119

2.3.9.8 Die Anbindung der Projektorganisation an die

Stammorganisation . . . . . . . . . . . . . . . . . . . . . . . . 119

2.3.9.9 Die Kompetenzregelung . . . . . . . . . . . . . . . . . . . . 125

2.3.9.10Bildung der Projektorganisation . . . . . . . . . . . . . . . . 128

2.3.10 Informationsbeschaffung und Situationsanalyse . . . . . . . . . . . 129

2.3.10.1Kontextanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . 130

2.3.10.2SWOT-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . 131

2.3.10.3Ursachen-Wirkungsanalyse . . . . . . . . . . . . . . . . . . 132

2.3.10.4Analyse der Rechtsgrundlagen und Compliance Vorgaben 134

XII

Inhaltsverzeichnis

2.3.10.5Schutzbedarfsanalyse . . . . . . . . . . . . . . . . . . . . . . 135

2.3.10.6Planhorizont . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

2.3.10.7Szenario-Technik . . . . . . . . . . . . . . . . . . . . . . . . . 135

2.3.11 Projektstrukturierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

2.3.11.1Vorgehen bei der Projektstrukturierung: . . . . . . . . . . . 138

2.3.11.2Im Projekt Meilensteine setzen: der Phasenplan . . . . . . 138

2.3.11.3Projekte, Teilprojekte, Arbeitspakete, Lieferobjekte und

Tätigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

2.3.11.4Der Projektstrukturplan PSP . . . . . . . . . . . . . . . . . . 142

2.3.12 Projektauftrag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

2.3.13 Projekthandbuch/Projektmanagementplan . . . . . . . . . . . . . . . 149

2.3.14 Kick-off-Veranstaltung

. . . . . . . . . . . . . . . . . . . . . . . . . . 149

2.3.15 Problemlösungsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . 152

2.3.16 Design Thinking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

2.3.17 Checkliste Abschluss Initialisierungsphase . . . . . . . . . . . . . . 157

2.4

Phase Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

2.4.1

Worauf kommt es in der Konzeptphase an? . . . . . . . . . . . . . . 160

2.4.2

Produktkonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

2.4.3

Product Backlog

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

2.4.4

Releaseplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

2.4.5

Pﬂichtenheft – Lösungskonzept . . . . . . . . . . . . . . . . . . . . . 170

2.4.6

Aufwandschätzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

2.4.6.1 Bedeutung der Aufwandschätzung in der klassischen

Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . 171

2.4.6.2 Planning Poker/Story Points . . . . . . . . . . . . . . . . . . 172

2.4.6.3 T-Shirt Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

2.4.6.4 Multiplikatoren Methode . . . . . . . . . . . . . . . . . . . . 173

2.4.6.5 Prozentsatzmethode . . . . . . . . . . . . . . . . . . . . . . . 173

2.4.6.6 Expertenschätzung (Delphi Methode) . . . . . . . . . . . . 173

2.4.6.7 PERT (Program Evaluation and Review Technique) . . . 173

2.4.6.8 Reserven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

2.4.6.9 Typische Fehler in der Aufwandschätzung . . . . . . . . . 174

2.4.7

Ablauf/Terminplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

2.4.7.1 Ablauf- und Terminplan erstellen . . . . . . . . . . . . . . . 174

2.4.7.2 Terminierung, kritischer Pfad und Schlupf . . . . . . . . . 176

2.4.7.3 Genauigkeit in der Ablauf- und Terminplanung . . . . . . 176

2.4.7.4 Vorgehensweisen bei der Planung . . . . . . . . . . . . . . . 178

2.4.7.5 Termintreue und kapazitätstreue Planung . . . . . . . . . . 181

2.4.7.6 Wie detailliert soll eine Planung sein? . . . . . . . . . . . . 182

2.4.7.7 Weitere Planungsvarianten: Target Costing, Design-to-

Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

2.4.8

Ressourceneinsatzplan und Ressourcenabstimmung . . . . . . . . . 184

Inhaltsverzeichnis

XIII

2.4.8.1 Ressourceneinsatzplanung im Projekt: Linie und

Projektleiter als Partner . . . . . . . . . . . . . . . . . . . . . 184

2.4.8.2 Ressourcenabstimmung im Multiprojektmanagement . . 185

2.4.9

Kostenplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

2.4.10 Information, Kommunikation und Dokumentation . . . . . . . . . . 189

2.4.10.1Grundsätze der Information und Kommunikation . . . . . 190

2.4.10.2Umfang eines Informations- und Kommunikationssystems 191

2.4.11 Qualitätsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

2.4.12 Checkliste Abschluss Konzeptphase . . . . . . . . . . . . . . . . . . 194

2.5

Phase Realisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

2.5.1

Worauf kommt es in der Phase Realisierung an? . . . . . . . . . . . 195

2.5.2

Sprintplanung/Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . 197

2.5.3

Sprintdurchführung/Daily Standup Meeting . . . . . . . . . . . . . . 200

2.5.4

Sprint Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

2.5.5

Retrospektive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

2.5.6

Projektcontrolling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

2.5.6.1 Projektkontrolle

. . . . . . . . . . . . . . . . . . . . . . . . . 206

2.5.6.2 Berichtswesen (Reporting) . . . . . . . . . . . . . . . . . . . 208

2.5.6.3 Projektsteuerung . . . . . . . . . . . . . . . . . . . . . . . . . 210

2.5.6.4 Projektbeurteilung . . . . . . . . . . . . . . . . . . . . . . . . 215

2.5.6.5 Das 90 %-Syndrom . . . . . . . . . . . . . . . . . . . . . . . 217

2.5.7

Termin-, Kosten- und Ressourcenkontrolle . . . . . . . . . . . . . . 218

2.5.7.1 Termin- und Kostenkontrolle

. . . . . . . . . . . . . . . . . 218

2.5.7.2 Ressourcenkontrolle . . . . . . . . . . . . . . . . . . . . . . . 220

2.5.7.3 Kostentransparenz und realistische Beurteilung der

wirtschaftlichen Projektsituation . . . . . . . . . . . . . . . 221

2.5.8

Projektänderungen, Change Request Management, Claim

Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

2.5.8.1 Projektänderungen . . . . . . . . . . . . . . . . . . . . . . . . 222

2.5.8.2 Änderungsmanagement (Change Request Management) . 223

2.5.8.3 Nachforderungsmanagement (Claim Management) . . . . 227

2.5.9

Checkliste Abschluss Realisierungsphase . . . . . . . . . . . . . . . 228

2.6

Phase Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

2.6.1

Worauf kommt es in der Einführungsphase an? . . . . . . . . . . . . 229

2.6.2

Einführungsarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

2.6.3

Abnahme und Inbetriebnahme . . . . . . . . . . . . . . . . . . . . . . 233

2.6.3.1 Abnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

2.6.3.2 Inbetriebnahme . . . . . . . . . . . . . . . . . . . . . . . . . . 233

2.6.3.3 Produktivsetzung in der agilen Vorgehensweise . . . . . . 233

2.6.3.4 Pilotversuch, Nullserie . . . . . . . . . . . . . . . . . . . . . 233

2.6.3.5 Von der Nullserie zur Serienproduktion . . . . . . . . . . . 234

2.6.4

Benutzerschulung/Ausbildung . . . . . . . . . . . . . . . . . . . . . . 234

XIV

Inhaltsverzeichnis

2.6.4.1 Konzeption Benutzerschulung . . . . . . . . . . . . . . . . . 234

2.6.4.2 Arten der Benutzerschulung . . . . . . . . . . . . . . . . . . 234

2.6.5

Überführung in die Betriebsorganisation . . . . . . . . . . . . . . . . 235

2.6.5.1 Vorbereitung Betrieb . . . . . . . . . . . . . . . . . . . . . . . 235

2.6.5.2 Betriebsorganisation . . . . . . . . . . . . . . . . . . . . . . . 235

2.6.5.3 Betriebsübergabe . . . . . . . . . . . . . . . . . . . . . . . . . 235

2.6.6

Projektabschluss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

2.6.7

Checkliste „Abschluss Einführungsphase“ . . . . . . . . . . . . . . 238

2.7

Projektportfolio- und Programmmanagement . . . . . . . . . . . . . . . . . 239

2.7.1

Projektportfolio und Multiprojektmanagement . . . . . . . . . . . . 239

2.7.1.1 Multiprojektmanagement: Problemfelder, Aufgabenfelder

und Elemente . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

2.7.1.2 Multiprojektmanagement-Prozess . . . . . . . . . . . . . . 241

2.7.1.3 Konﬁguration des Portfolios . . . . . . . . . . . . . . . . . . 242

2.7.1.4 Priorisierte Projektliste . . . . . . . . . . . . . . . . . . . . . 243

2.7.1.5 Inhaltliche Abhängigkeiten . . . . . . . . . . . . . . . . . . . 246

2.7.1.6 Ressourcenverfügbarkeit und -abhängigkeiten . . . . . . . 247

2.7.1.7 Das Projektportfolio . . . . . . . . . . . . . . . . . . . . . . . 248

2.7.1.8 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

2.7.1.9 Stufen zu einem exzellenten Portfoliomanagement . . . . 250

2.7.2

Programmmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . 250

2.7.2.1 Was kennzeichnet ein Programm? . . . . . . . . . . . . . . 251

2.7.2.2 Mehrwert der Programmorganisation . . . . . . . . . . . . 252

2.7.2.3 Unterscheidung Projekt- und Programmmanagement . . . 252

2.7.3

Project Management Ofﬁce – PMO . . . . . . . . . . . . . . . . . . . 252

2.7.4

Projektmanagementhandbuch . . . . . . . . . . . . . . . . . . . . . . 254

2.8

Lösungsﬁndung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

2.8.1

Kreativitätstechnik, Lösungsﬁndung und Lösungsauswahl . . . . . 255

2.8.1.1 Ohne Neugierde keine Kreativität . . . . . . . . . . . . . . . 255

2.8.1.2 Möglichkeiten, kreativ zu werden . . . . . . . . . . . . . . . 256

2.8.1.3 Brainstorming . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

2.8.1.4 Analogie: Bionik und Synektik . . . . . . . . . . . . . . . . 259

2.8.1.5 Lösung herstellen

. . . . . . . . . . . . . . . . . . . . . . . . 260

2.8.1.6 Lösungstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

2.8.1.7 Lösungssuche: Optimierung . . . . . . . . . . . . . . . . . . 261

2.8.1.8 Lösungssuche: Lösungen analysieren . . . . . . . . . . . . 262

2.8.2

Lösungen bewerten und entscheiden . . . . . . . . . . . . . . . . . . 262

2.8.2.1 Nutzwertanalyse und Kosten-Wirksamkeitsanalyse . . . . 262

2.8.2.2 Alternativen zur Nutzwertanalyse . . . . . . . . . . . . . . . 266

2.8.2.3 Übersicht über die Vorgehensschritte der

Lösungsbewertung . . . . . . . . . . . . . . . . . . . . . . . . 267

2.9

Beschaffung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

Inhaltsverzeichnis

2.9.1

Beschaffungsvorgehen in der agilen Vorgehensweise . . . . . . . . 268

2.9.1.1 Beschaffungsbedarf klären . . . . . . . . . . . . . . . . . . . 269

2.9.1.2 Geeignete Anbieter auswählen . . . . . . . . . . . . . . . . 269

2.9.1.3 Umsetzung eines Pilotprojektes . . . . . . . . . . . . . . . . 269

2.9.1.4 Vertrag verhandeln und Beschaffung abschließen . . . . . 270

2.9.2

Beschaffungsvorgehen in der klassischen Vorgehensweise . . . . . 270

2.9.2.1 Beschaffungsbedarf klären . . . . . . . . . . . . . . . . . . . 270

2.9.2.2 Beschaffungsplan erstellen . . . . . . . . . . . . . . . . . . . 270

2.9.2.3 Ausschreibungsunterlagen erstellen . . . . . . . . . . . . . 272

2.9.2.4 Ausschreibung und Evaluation durchführen . . . . . . . . 273

2.9.2.5 Vertrag verhandeln und Beschaffung abschließen . . . . . 274

Literatur

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

Mensch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

3.1

Kompetenzmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

3.2

Bedingungen für gute Leistung . . . . . . . . . . . . . . . . . . . . . . . . . . 276

3.3

Phänomen Mensch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

3.3.1

Wer sind wir? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

3.3.2

Wunderwerk Hirn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

3.3.3

Grundbedürfnisse bestimmen unser Leben . . . . . . . . . . . . . . 282

3.3.4

Spezielle Bedürfnisse der Generation Y . . . . . . . . . . . . . . . . 285

3.3.5

Wahrnehmung des Menschen

. . . . . . . . . . . . . . . . . . . . . . 287

3.3.6

Bewusstsein und Selbstreﬂexion . . . . . . . . . . . . . . . . . . . . . 289

3.3.7

Vertrauen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290

3.3.8

Humor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

3.4

Persönliche Kultur und Werte . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

3.4.1

Was ist Kultur? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

3.4.2

Organisationskultur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

3.4.3

Sich der eigenen kulturellen Prägung bewusst werden . . . . . . . 294

3.5

Stress und Veränderung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

3.5.1

Hintergründe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

3.5.2

Psychischer Stress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

3.5.3

Leben heißt Veränderung . . . . . . . . . . . . . . . . . . . . . . . . . 296

3.5.4

Persönliche Bewältigungsstrategien und Dilemmata . . . . . . . . . 297

3.5.5

Angst als Auslöser der Stressreaktion

. . . . . . . . . . . . . . . . . 298

3.5.6

Kontrollierbare Stressreaktion . . . . . . . . . . . . . . . . . . . . . . 298

3.5.7

Unkontrollierbare Stressreaktion . . . . . . . . . . . . . . . . . . . . . 299

3.5.8

Bewältigung von Stressoren in der Projektarbeit . . . . . . . . . . . 299

3.5.9

Burnout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

3.6

Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302

3.7

Motivation und Sinn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

3.7.1

Zielorientierung des Menschen

. . . . . . . . . . . . . . . . . . . . . 304

XVI

Inhaltsverzeichnis

3.7.2

Was ist Motivation?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

3.7.2.1 Gallup: Engagement und Motivation bei der Arbeit . . . . 305

3.7.2.2 Intrinsische und extrinsische Motivation

. . . . . . . . . . 305

3.7.2.3 Motivation durch Bearbeitung der Demotivationsfaktoren 306

3.7.3

Sinn als intrinsischer Motivator . . . . . . . . . . . . . . . . . . . . . 306

3.7.3.1 Was ist Sinn? . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

3.7.3.2 Lebenssinn ¤ Sinn des Lebens . . . . . . . . . . . . . . . . 307

3.7.3.3 Unsere Lebensweise zerstört systematisch Sinn . . . . . . 307

3.7.3.4 Sinnerfüllung im Beruf? . . . . . . . . . . . . . . . . . . . . 308

3.8

Selbstmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

3.8.1

Handlungsfähigkeit des Menschen . . . . . . . . . . . . . . . . . . . 309

3.8.2

Persönlicher Kompetenzkreis: Stärken und Schwächen . . . . . . . 310

3.8.3

Zeitmanagement und Arbeitstechnik . . . . . . . . . . . . . . . . . . 311

3.8.4

Resilienz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

3.8.4.1 Was ist Resilienz? . . . . . . . . . . . . . . . . . . . . . . . . 313

3.8.4.2 Grundhaltungen . . . . . . . . . . . . . . . . . . . . . . . . . 315

3.8.5

Umgang mit Scheitern . . . . . . . . . . . . . . . . . . . . . . . . . . . 316

3.8.5.1 Scheitern bei Roche und Dyson . . . . . . . . . . . . . . . . 316

3.8.5.2 Persönliche Anteile: Haltung

. . . . . . . . . . . . . . . . . 317

3.8.5.3 Organisationale Anteile . . . . . . . . . . . . . . . . . . . . . 317

3.8.5.4 Fail fast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

3.9

Persönliche Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

3.9.1

Was ist Kommunikation? . . . . . . . . . . . . . . . . . . . . . . . . . 318

3.9.2

Axiomtheorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

3.9.3

Kommunikationsquadrat . . . . . . . . . . . . . . . . . . . . . . . . . 319

3.9.4

Kommunikationskreislauf . . . . . . . . . . . . . . . . . . . . . . . . . 322

3.9.5

Meta-Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

3.9.6

Ich- und Du Botschaft . . . . . . . . . . . . . . . . . . . . . . . . . . . 325

3.9.7

Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325

3.9.7.1 Johari-Fenster . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

3.9.7.2 Johari-Fenster in der persönlichen Weiterentwicklung . . 328

3.9.7.3 Feedbackregeln . . . . . . . . . . . . . . . . . . . . . . . . . . 328

3.9.8

Fragetechniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

3.9.8.1 Offene und geschlossene Fragen . . . . . . . . . . . . . . . 330

3.9.8.2 Aktives Zuhören . . . . . . . . . . . . . . . . . . . . . . . . . 332

3.9.8.3 Weitere Fragetypen . . . . . . . . . . . . . . . . . . . . . . . 334

3.10 Persönliche Weiterentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . 335

3.10.1 Die drei Lebenswelten . . . . . . . . . . . . . . . . . . . . . . . . . . . 335

3.10.2 Selbsterkenntnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336

3.10.2.1Belbin

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

3.10.2.2MBTI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340

3.10.3 Coaching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340

Inhaltsverzeichnis

XVII

3.10.4 Intervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

3.10.5 Upside- oder Downside-Strategie? . . . . . . . . . . . . . . . . . . . 343

Literatur

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344

Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

4.1

Zusammenarbeit und Führung . . . . . . . . . . . . . . . . . . . . . . . . . . 347

4.1.1

Zusammenarbeit im Projekt

. . . . . . . . . . . . . . . . . . . . . . . 347

4.1.2

Führung – was ist das? . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

4.1.3

Macht und Autorität . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

4.1.3.1 Ermächtigung und Bemächtigung: Macht basiert auf

Beziehung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

4.1.3.2 Klassische Quellen der Macht . . . . . . . . . . . . . . . . . 351

4.1.3.3 Weitere Machtquellen im Projektmanagement . . . . . . . 352

4.1.3.4 Projekte benötigen immer auch geliehene Macht . . . . . 353

4.1.3.5 Machtquellen: Zwischen Person und Institution . . . . . . 354

4.1.3.6 Autorität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

4.1.4

Anbindung der Projektorganisation an die Stammorganisation . . 356

4.1.5

Aufgabe-Kompetenz-Verantwortung (A-K-V) . . . . . . . . . . . . 357

4.1.6

Vom vorauseilenden Gehorsam in den konstruktiven Ungehorsam 358

4.1.7

Unterschiedliche Ausprägungen von Führung . . . . . . . . . . . . 359

4.1.8

Delegation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361

4.1.9

„Aufstellung“ in Teams: Position und Rolle . . . . . . . . . . . . . . 364

4.1.10 Rollenträger und Rollensender . . . . . . . . . . . . . . . . . . . . . . 367

4.1.11 Rolle als Bindeglied zwischen Organisation und Person . . . . . . 367

4.1.12 Speziﬁsche Eigenschaften im agilen Projekt . . . . . . . . . . . . . 370

4.1.12.1Grundsätze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

4.1.12.2Gewichtete Kompetenzproﬁle Product Owner und Scrum

Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

4.1.12.3Wie funktioniert Selbststeuerung? . . . . . . . . . . . . . . 372

4.1.12.4Wann ist Selbststeuerung sinnvoll? . . . . . . . . . . . . . . 372

4.1.12.5In eigener Kompetenz über Vorgehen und Lösungen

entscheiden . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

4.1.12.6Müssen Mitglieder selbstgesteuerter Teams besonders

ausgebildet sein? . . . . . . . . . . . . . . . . . . . . . . . . . 373

4.1.12.7Kollegiale Führung innerhalb selbstgesteuerter Teams . . 373

4.1.12.8Vertrauen als Voraussetzung für selbstgesteuerte Teams . 374

4.1.12.9Indirekte Führung – Leadership neu deﬁniert . . . . . . . . 374

4.1.13 Speziﬁsche Eigenschaften im klassischen Projekt . . . . . . . . . . 377

4.1.13.1Grundsätze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

4.1.13.2Gewichtete Kompetenzproﬁle Projektleiter und

Auftraggeber . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

4.1.13.3Führungsstile . . . . . . . . . . . . . . . . . . . . . . . . . . . 378

XVIII

Inhaltsverzeichnis

4.1.13.4Führen über Ziele (Management by Objectives MbO) . . 383

4.1.13.5Schlüsselpositionen im Projektteam . . . . . . . . . . . . . 385

4.1.13.6Aspekte der Projektteamzusammensetzung . . . . . . . . . 386

4.1.14 Einﬂussfaktoren für die erfolgreiche Zusammenarbeit . . . . . . . 388

4.1.14.1Belbin Teamrollen . . . . . . . . . . . . . . . . . . . . . . . . 388

4.1.14.2Projektkultur . . . . . . . . . . . . . . . . . . . . . . . . . . . 391

4.1.14.3Radical Collaboration . . . . . . . . . . . . . . . . . . . . . . 392

4.1.14.4Multikulturelle Zusammenarbeit . . . . . . . . . . . . . . . 394

4.1.14.5Mit virtuellen Teams effektiv kommunizieren . . . . . . . 399

4.1.14.6Organisationsaufstellungen . . . . . . . . . . . . . . . . . . . 400

4.2

Dynamik in Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403

4.2.1

Forming: Orientierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 403

4.2.2

Storming: Auseinandersetzung . . . . . . . . . . . . . . . . . . . . . . 404

4.2.3

Norming: Vertrautheit . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

4.2.4

Performing: Arbeit im System . . . . . . . . . . . . . . . . . . . . . . 407

4.2.5

Adjourning: Abschied und Trennung . . . . . . . . . . . . . . . . . . 408

4.2.6

Dynamiken und Wechselwirkungen . . . . . . . . . . . . . . . . . . . 409

4.3

Verhandlungsführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409

4.3.1

Verhandlungen im Projektmanagement . . . . . . . . . . . . . . . . . 409

4.3.2

Was ist eine Verhandlung? . . . . . . . . . . . . . . . . . . . . . . . . 410

4.3.3

Verhandlungszyklus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410

4.3.3.1 Vorbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

4.3.3.2 Optimale Verhandlungsstrategie und Taktik: Situativ . . . 416

4.3.3.3 Verhandlungsführung . . . . . . . . . . . . . . . . . . . . . . 417

4.3.3.4 Auswertung und Controlling . . . . . . . . . . . . . . . . . . 419

4.3.4

Verhandlung nach dem Harvard-Konzept führen . . . . . . . . . . . 419

4.3.4.1 Trennung zwischen Person und Sache . . . . . . . . . . . . 419

4.3.4.2 Interessen anstatt Positionen . . . . . . . . . . . . . . . . . . 420

4.3.4.3 Kriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421

4.3.4.4 Möglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . 421

4.3.4.5 Auswahl nach dem BATNA-Prinzip . . . . . . . . . . . . . 421

4.4

Konﬂiktmanagement und Krisen . . . . . . . . . . . . . . . . . . . . . . . . . 422

4.4.1

Was ist ein Konﬂikt? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422

4.4.2

Ursprung und Symptom: Das systemische Phänomen . . . . . . . . 424

4.4.3

Konﬂiktsyndrom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427

4.4.4

Konﬂiktsymptome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429

4.4.5

Potenzial von Konﬂikten . . . . . . . . . . . . . . . . . . . . . . . . . 429

4.4.6

Was passiert bei Konﬂikten in unserem Gehirn? . . . . . . . . . . . 430

4.4.6.1 Erregung im Gehirn . . . . . . . . . . . . . . . . . . . . . . . 430

4.4.6.2 Verlust von Selbstreﬂexion und Selbststeuerung . . . . . . 431

4.4.6.3 Konﬂikte verletzen die Grundbedürfnisse des Menschen

432

4.4.6.4 Konﬂikte tun weh . . . . . . . . . . . . . . . . . . . . . . . . 433

Inhaltsverzeichnis

XIX

4.4.7

Konﬂiktarten im Projektmanagement . . . . . . . . . . . . . . . . . . 433

4.4.7.1 Ziel- und Interessenkonﬂikt . . . . . . . . . . . . . . . . . . 433

4.4.7.2 Verteilungs- und Ressourcenkonﬂikt . . . . . . . . . . . . . 435

4.4.7.3 Struktureller und organisatorischer Konﬂikt . . . . . . . . 435

4.4.7.4 Bewertungskonﬂikt . . . . . . . . . . . . . . . . . . . . . . . 436

4.4.7.5 Rollenkonﬂikt . . . . . . . . . . . . . . . . . . . . . . . . . . . 436

4.4.7.6 Persönlicher Konﬂikt . . . . . . . . . . . . . . . . . . . . . . 437

4.4.7.7 Beziehungskonﬂikt (Sozialer Konﬂikt) . . . . . . . . . . . 439

4.4.7.8 Wertekonﬂikt . . . . . . . . . . . . . . . . . . . . . . . . . . . 441

4.4.8

Konﬂiktdiagnose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441

4.4.8.1 Hypothesen bilden statt wissen wollen . . . . . . . . . . . . 441

4.4.8.2 Äußerungsform von Konﬂikten . . . . . . . . . . . . . . . . 442

4.4.8.3 Konﬂiktstile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444

4.4.9

Modelle zur Konﬂiktdiagnose . . . . . . . . . . . . . . . . . . . . . . 447

4.4.9.1 Konﬂikt-Eskalationsstufen . . . . . . . . . . . . . . . . . . . 447

4.4.9.2 Schichtenmodell . . . . . . . . . . . . . . . . . . . . . . . . . 449

4.4.9.3 Fragen zur Konﬂiktdiagnose . . . . . . . . . . . . . . . . . . 452

4.4.10 Konﬂiktbewältigung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454

4.4.10.1Das Ziel von Konﬂiktmanagement . . . . . . . . . . . . . . 454

4.4.10.2Die Selbststeuerung wiederherstellen . . . . . . . . . . . . 454

4.4.10.3Prozess der Konﬂiktbewältigung . . . . . . . . . . . . . . . 455

4.4.10.4Harvard-Konzept in der Konﬂiktbewältigung . . . . . . . . 459

4.4.11 Konﬂiktbewältigung je nach Konﬂiktart . . . . . . . . . . . . . . . . 463

4.4.11.1Ziel- und Interessenkonﬂikt . . . . . . . . . . . . . . . . . . 463

4.4.11.2Verteilungs- und Ressourcenkonﬂikt . . . . . . . . . . . . . 464

4.4.11.3Struktureller und organisatorischer Konﬂikt . . . . . . . . 465

4.4.11.4Bewertungskonﬂikt . . . . . . . . . . . . . . . . . . . . . . . 465

4.4.11.5Rollenkonﬂikt . . . . . . . . . . . . . . . . . . . . . . . . . . . 466

4.4.11.6Persönlicher Konﬂikt . . . . . . . . . . . . . . . . . . . . . . 467

4.4.11.7Beziehungskonﬂikt (sozialer Konﬂikt) . . . . . . . . . . . . 468

4.4.11.8Wertekonﬂikt . . . . . . . . . . . . . . . . . . . . . . . . . . . 470

4.4.11.9Zusammenfassung Konﬂiktbewältigung . . . . . . . . . . . 472

4.4.12 Konﬂiktprävention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472

4.4.12.1Projektmanagement Methodik . . . . . . . . . . . . . . . . . 472

4.4.12.2Störungen haben Vorrang . . . . . . . . . . . . . . . . . . . . 473

4.4.12.3Konﬂiktfähigkeit und Frustrationstoleranz . . . . . . . . . 473

4.4.13 Umgang mit Krisen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474

4.5

Veränderung und Widerstand . . . . . . . . . . . . . . . . . . . . . . . . . . . 476

4.5.1

Change und Transformation . . . . . . . . . . . . . . . . . . . . . . . 476

4.5.1.1 Change: Probleme lösen . . . . . . . . . . . . . . . . . . . . 477

4.5.1.2 Transformation: Lösungen ﬁnden . . . . . . . . . . . . . . . 477

4.5.2

Mind Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478

Inhaltsverzeichnis

4.5.3

Der Mensch und Veränderung . . . . . . . . . . . . . . . . . . . . . . 478

4.5.4

„Formel“ der Veränderung . . . . . . . . . . . . . . . . . . . . . . . . 480

4.5.5

Veränderungsbereitschaft in Organisationen . . . . . . . . . . . . . . 481

4.5.6

Psychologik und Sachlogik in Projekten . . . . . . . . . . . . . . . . 482

4.5.7

Gestaltungswille und Kooperationsbereitschaft . . . . . . . . . . . . 483

4.5.8

Veränderungsprozess-Modell . . . . . . . . . . . . . . . . . . . . . . . 484

4.5.8.1 Phasen der Veränderung . . . . . . . . . . . . . . . . . . . . 484

4.5.8.2 Ungleichzeitigkeit . . . . . . . . . . . . . . . . . . . . . . . . 486

4.5.9

Umgang mit Widerstand . . . . . . . . . . . . . . . . . . . . . . . . . . 486

4.5.9.1 Positive und negative Konnotation . . . . . . . . . . . . . . 486

4.5.9.2 Ist Widerstand ein Synonym für Konﬂikt? . . . . . . . . . 488

4.5.9.3 Formen von Widerstand . . . . . . . . . . . . . . . . . . . . . 488

4.5.9.4 Umgang mit Widerstand . . . . . . . . . . . . . . . . . . . . 489

4.5.9.5 Interventionen bei Widerstand . . . . . . . . . . . . . . . . . 492

4.6

Zum Schluss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492

Literatur

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492

Referenzliste zur Individual Competence Baseline (ICB) der IPMA . . . . 495

Über die Autoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507

Sachverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511

Einleitung

1.1

Projektmanagement, wozu?

Veränderungsgeschwindigkeit und Komplexität haben in den letzten Jahren drastisch zu-

genommen. Die Organisationsstrukturen behindern mehr als sie nützen. Organisationen

sind zu fragmentiert und zu hierarchisch strukturiert. Damit sind sie für interdisziplinäre

Zusammenarbeit und rasche Entscheide zu schwerfällig. Vorhaben lassen sich mit den

etablierten Abläufen kaum mehr bewältigen. Gefordert sind neue Organisationsformen

und Strukturen. Diese müssen vor allem efﬁziente Führungs- und Kommunikationswege

ermöglichen.

Projektmanagement wurde in den Fünfzigerjahren des 20. Jahrhunderts in der Raum-

fahrt und im Anlagebau entwickelt. Für diese Projekte wurden spezielle Planungsmetho-

den wie z. B. die Netzplantechnik (Critical Path Method) oder PERT (Program Evaluation

and Review Technique) entwickelt. Diese wurden zur Lösung komplexer Aufgaben nicht

nur bei technischen Aufgabenstellungen, sondern auch bei Problem- und Krisensitua-

tionen in allen Funktionen des Managements eingesetzt: beispielsweise für Marketing,

Personalwesen, Finanzen und Organisation in privatwirtschaftlichen Unternehmen und

öffentlichen Verwaltungen. Die klassischen Vorgehensweisen haben heute immer noch

Gültigkeit und werden breit angewendet. In verschiedenen Bereichen wie beispielsweise

der Produkt- oder Softwareentwicklung stoßen sie aber an ihre Grenzen. Agile Metho-

den wie beispielsweise Scrum helfen weiter. Die agilen Methoden setzen auf das Prinzip

der Selbstorganisation von Teams. Sie sind bewusst schlank aufgestellt und auf schnel-

le, iterative Lieferung von Resultaten und Prototypen fokussiert. Aus der klassischen und

agilen Vorgehensweise haben sich Mischformen entwickelt, welche als hybrides Projekt-

management bezeichnet werden. Umfassen Vorhaben betriebliche, strukturelle, organisa-

torische oder personelle Aspekte, wird Projektmanagement oft auch Change-Management

genannt.

Das klassische Projektmanagement hat im Industriezeitalter des Taylorismus zu efﬁ-

zienten Vorgehensweisen verholfen. Heute, im Wissenszeitalter der Netzwerkökonomie

J. Kuster et al., Handbuch Projektmanagement, https://doi.org/10.1007/978-3-662-57878-0_1

Einleitung

Efﬁzienz

Methode

Regeln

Maschine

Mensch

Zeit

Wer?

Wie?

Handwerk

Anteil Wertschöpfung

enge lokale Märkte

1900

1980

2000

Innovations-

druck

Efﬁzienz-

druck

kompliziert

komplex

Wissen

Ausprobieren

Sinn

Manufaktur

Taylorismus/

Industriezeitalter

Netzwerkökonomie

weite globale Märkte

enge globale Märkte

Marktdruck

Abb. 1.1 Taylorwanne

bestimmen Komplexität und Dynamik den Alltag der Unternehmen. Bernd Oestereich

und Claudia Schröder stellen dies auf Taylorwanne von Wohland et al. 2004 und Pﬂae-

ging et al. 2015 in Abb. 1.1 dar.

Auf den intensiven Wettbewerb und die gesteigerte Nachfrage nach personalisierten

Angeboten müssen sich die Unternehmen einstellen. Um die hohe Dynamik und Komple-

xität im Alltag zu meistern, setzen sie eher agile Vorgehensweisen im Projektmanagement

ein. Je nach Situation, in welcher sich eine Organisation beﬁndet, wählt sie die entspre-

chende Vorgehensweise.

Folgende Merkmale charakterisieren das Projektmanagement:

Eine einfache, ﬂexible und rasch reaktionsfähige temporäre Organisation sorgt für die

optimale Abwicklung des jeweiligen Vorhabens.

Das Projektmanagement erleichtert und fördert die direkte, interdisziplinäre Zusam-

menarbeit.

Die Kompetenzen der Führung sind in der Projektorganisation geklärt.

Die direkten Kommunikationswege innerhalb und außerhalb des Projektes sind leicht

zugänglich.

1.2

Was sind Projekte?

Das vorhandene Leistungspotential wird durch Teamarbeit und eine stimulierende At-

mosphäre aktiviert.

Klare Zugehörigkeit zum Projektteam erleichtert es, Loyalitätskonﬂikte zu erkennen

und zu bearbeiten.

Der Einbezug der betroffenen Personen ermöglicht es, eine lernende Organisation zu

sein.

1.2

Was sind Projekte?

Eine allgemein gültige Deﬁnition des Begriffs Projekt hat sich nicht durchgesetzt. Or-

ganisationen deﬁnieren Projekte nach ihren Bedürfnissen unterschiedlich. Die folgenden

gemeinsamen Merkmale lassen sich festhalten:

Projekte sind zielgerichtete Vorhaben. Sie bewirken Veränderungen, die sehr unter-

schiedliche Reaktionen auslösen können: von Euphorie bis Widerstand, von Skepsis

und Angst bis Freude und Motivation. Sie stellen große organisations-psychologische

Ansprüche an die Projektleitung.

Projekte sind Innovationen. Entweder stoßen sie an die Grenze des technisch oder

organisatorisch bisher Machbaren (z. B. neue Informations- und Kommunikationstech-

nologien), oder sie sind für die Organisation etwas völlig Neues, wofür erstmals Wissen

aufgebaut werden muss (z. B. Selbstorganisation).

Projekte sind abgegrenzte Vorhaben: Sie sind einmalig, zeitlich begrenzt und unter

Termindruck.

Projekte sind interdisziplinär: Sie überschreiten die gewöhnliche Organisationsstruktur

der Linie und tangieren verschiedene Disziplinen und Verantwortungsbereiche.

Projekte sind von hoher fachlicher und sozialer Komplexität.

der Projektcharakter ändert sich von Phase zu Phase (Vision, Konzept, Ausführung)

und erfordert unterschiedliche Managementfähigkeiten.

Projekte sind schwierig zu planen und zu steuern, verlangen besondere organisatorische

Maßnahmen sowie klare und eindeutige Entscheide.

Projekte brauchen außerordentliche Ressourcen bezüglich Führung, Wissen, Personal,

Finanzen.

Projekte weisen je nach Größe und Komplexität verschiedene Risiken ﬁnanzieller, per-

soneller, fachlicher und terminlicher Art auf.

Projekte verlangen für ihre Abwicklung eine eigene Projektorganisation: „Projekte sind

Organisationen“.

Einleitung

Das Autorenteam deﬁniert „Projekt“ wie folgt:

Ein Projekt ist ein einmaliges, bereichsübergreifendes, zeitlich begrenztes, zielge-

richtetes und interdisziplinäres Vorhaben, das so wichtig, kritisch und dringend ist,

dass es nicht in der bestehenden Linienorganisation bearbeitet werden kann, sondern

besondere organisatorische Vorkehrungen erfordert.

Vorhaben, welche zwar nicht Projekte sind, bei denen jedoch einzelne Elemente des

Projektmanagements zur Anwendung kommen, sind unter anderem:

einmalige Sonderaufträge, die im Wesentlichen durch eine Person, also ohne eigene

Projektorganisation, erfüllt werden können;

kontinuierliche Prozesse wie Lern-, Fertigungs-, Entwicklungs- oder Veränderungspro-

zesse ohne deﬁniertes Ende. Sie sind wie ein Strom. Darin können allerdings Projek-

te eingelagert sein. Beispielsweise werden Konzeption und Einführung eines Quali-

tätsmanagementsystems meist als Projekt abgewickelt, um damit auch weiterlaufende

Rückkoppelungs- und Lernprozesse zu installieren.

Die Grundsätze und Methoden des Projektmanagements können für solche Vorhaben

weitgehend übernommen werden.

1.2.1

Projektausprägungen

Der Projektcharakter gibt dem Projektleiter wichtige Hinweise, wie er das Projekt struk-

turiert, die Projektorganisation deﬁniert und welche Ressourcen er dazu benötigt. Es gibt

verschiedene Möglichkeiten, Projekte zu charakterisieren.

Man unterscheidet Projekte nach der Ausprägung ihrer Aufgabenstellung: geschlos-

sen/offen und nach ihrer sozialen Komplexität: tief/hoch (Tab. 1.1). Aus Abb. 1.2 lassen

sich vier Projektausprägungen ableiten:

Standardprojekte können auf reiche Erfahrung zurückgreifen und demzufolge stan-

dardisiert und einfach abgewickelt werden. Beispiele: technisches Kundenprojekt, Er-

satzinvestition.

Akzeptanzprojekte sind Vorhaben mit klar umrissenen Aufgabenstellungen. Auf-

grund der Erfahrungen können Methoden und Hilfsmittel bis zu einem gewissen Grade

formalisiert und standardisiert werden. Da sie oft mit Akzeptanzproblemen verbun-

den sind, spielt die Kommunikation mit den Stakeholdern eine entscheidende Rolle.

Beispiele: Straßenbau-Projekt, komplexes Software-Projekt.

1.2

Was sind Projekte?

Tab. 1.1 Projektausprägungen

Aufgabenstellung

Geschlossen

Bekannte, klare Aufgabenstellung mit begrenzten Lö-

sungsmöglichkeiten, z. B. bauliche Erweiterung für

bestimmte Nutzungen

Offen

Viele Möglichkeiten bezüglich Inhalt und Vorgehen ohne

Lösungsvorstellungen, z. B. Verbesserung der Flexibilität

und Reaktionsgeschwindigkeit einer Organisation

Soziale Komplexität Tief

Unproblematische Zusammenarbeit, z. B. wenige

Anspruchsgruppen, wenig ausgeprägte Interessenun-

terschiede, Zusammenarbeit hauptsächlich in einem

Fachgebiet

Hoch

Interdisziplinär, politisch brisant, unterschiedliche Benut-

zerinteressen, großes Konﬂiktpotential

Hoch

Bereichsübergreifend,

interdisziplinär, komplizierte

Wirkungszusammenhänge

Geschlossen

Klare Aufgabenstellung

Offen

Aufgabenstellung mit vielen

inhaltlichen und vorgehens-

mässigen Möglichkeiten

Tief

Hauptsächliche Zusam-

menarbeit im Fachgebiet,

einfache Wirkungszusam-

menhänge, kleines Risiko

Aufgabenstellung

soziale Komplexität

Akzeptanzprojekt

Pionierprojekt

Standardprojekt

Potenzialprojekt

Abb. 1.2 Projektausprägungen

Potentialprojekte sind Aufgaben mit offenen Fragestellungen, die jedoch mit dem

Projektumfeld (noch) wenig vernetzt und diesbezüglich wenig risikoreich sind. Die

Projektorganisation ist hier meist einfach und klein. In diese Kategorie fallen Studi-

en, Potentialabklärungen, Machbarkeitsstudien, oft auch Forschungsprojekte. Beispiel:

Produktinnovationen, Entwicklung neuer Geschäftsmodelle.

Einleitung

Pionierprojekte sind folgenreiche Eingriffe in die Organisation, übergreifen mehre-

re Bereiche, haben hohen Neuigkeitsgehalt und sind für viele Betroffene bedrohlich

und risikoreich. Der Aufgabenumfang ist schwer abzuschätzen. Beispiel: Fusion zwei-

er Firmen, Entwicklung selbstfahrender Fahrzeuge.

Viele Projekte wechseln während ihrer Entwicklung von der Initialisierungsphase bis

zur Einführung den Projektcharakter. Oft wandeln sie sich vom Potentialprojekt zum Pio-

nierprojekt und werden dann zum Akzeptanzprojekt oder gar zum Standardprojekt.

Diese Typologie kann nicht nur Hinweise geben über den grundsätzlichen Projekt-

management-Ansatz, die Wahl der Projektorganisation, die Ausprägung der Kommuni-

kation oder der methodischen Schwerpunkte, sondern auch über die nötigen Stärken und

Qualiﬁkationen des Projektleiters. So erfordert z. B. ein Bauprojekt andere Qualiﬁkatio-

nen als ein Change-Projekt, ein Entwicklungsprojekt oder ein Auftragsabwicklungspro-

jekt.

Für die Abwicklung von Standardprojekten eignet sich die klassische Vorgehensweise

gut. Hingegen sind für die Abwicklung von Pionier-, Potential- und selbst von Akzeptanz-

projekten agile Vorgehensweisen besser geeignet.

Die Schätzung von Terminen und Kosten ist in Standard- und Akzeptanzprojekten

einfacher. Termine und Kosten können mit einer geringen Toleranz geplant werden. Hin-

gegen ist die Schätzung der Aufwände und die Ableitung eines möglichen Terminplans in

Potential- und Pionierprojekten viel anspruchsvoller und in der Tendenz mit einer höheren

Unsicherheit und Unschärfe verbunden.

1.2.2

Projektarten

Eine weitere Möglichkeit, Projekte zu klassiﬁzieren, besteht darin, sie nach ihrem Zweck

zu ordnen. Für einige Zwecke wurden von entsprechenden Gremien eigene Projektvorge-

hen entwickelt und standardisiert. Typische Projektarten sind:

Investitions-Projekte

Produktentwicklungs-Projekte

Organisationsentwicklungs-Projekte

Change-Projekte

Informatik-/Kommunikations-Projekte (IKT-Projekte), Softwareentwicklung, IKT-In-

frastrukturprojekte

Auftragsabwicklungsprojekte, Kundenprojekte

Prozessoptimierungsprojekte, Efﬁzienzsteigerungsprojekte

Infrastruktur-Projekte

Bauprojekte

Forschungs- und Entwicklungsprojekte

Near-/Offshore Projekte

1.2

Was sind Projekte?

Tab. 1.2 Beurteilung der Projektwürdigkeit und Ausprägung

Kriterium

Beschreibung

Einschätzung = 1

(1 Punkt)

Einschätzung = 2 (2 Punkte)

Einschätzung = 3 (3 Punkte)

Personenkreis

Von der Lösung betroffene Stellen,

betroffene Organisationseinheiten

Einzelne, aus gleicher

Abteilung

Einige, arbeiten zusammen

Beinahe aus dem ganzen Un-

ternehmen

Interdiszipli-

narität

Anzahl Organisationseinheiten, die

am Entstehungsprozess mitarbeiten

Nur eine

Wenige

Viele

Komplexität

Grad der Vernetztheit von verschie-

denen Problemstellungen

Gering, klar

Mittel, überschaubar

Hoch, schwierig vernetzbar,

noch nicht überschaubar

Wichtigkeit

Strategische Wichtigkeit des

Vorhabens für den Bereich, das

Unternehmen

Unbedeutend, klein

Mittel, strategisch wichtig für

Teile des Unternehmens

Gross, strategisch wichtig für

das gesamte Unternehmen,

Schlüsselfunktion

Dringlichkeit

Zeitlicher Druck: Wie schnell müs-

sen Lösungen verfügbar sein?

Problemlos

Fixer Termin, genügend Zeit

vorhanden

Zeitkritisch, anspruchsvoller,

ﬁxer Termin

Finanzieller

Aufwand

Investitionen?

Klein, ca. < C 0,5 Mio.,

gut verkraftbar

Mittel, ca. C 0,5 bis 1 Mio.,

braucht spezielle Vorkehrung

Hoch, > C 1 Mio., sprengt

Budgetkompetenz, braucht

Entscheid des Vorstands

Finanzieller

Zeitrahmen

In welchem Zeitrahmen sind die In-

vestitionen zu amortisieren: Return

on Investment (ROI)?

Schnell, im laufenden Jahr,

unbedeutend

Tragbar, innerhalb von ein bis

zwei Jahren

Wesentliche Belastung für

Unternehmen, braucht mehrere

Jahre

Aufwand

Durchführungsdauer? Interner Per-

sonalaufwand?

Gering, tangiert Tagesge-

schäft nicht

Mittel, mit bestehenden

Ressourcen machbar, im Ta-

gesgeschäft möglich

Hoch, erfordert zusätzliche

Ressourcen, sprengt Tagesge-

schäft

Wissen

Verfügt das Unternehmen über das

notwendige Wissen?

Vorhanden, Routinepro-

jekt, Standards vorhanden

Teilweise vorhanden bei

Schlüsselpersonen, wenig

Standards

Nicht vorhanden, muss aufge-

baut werden, keine Standards

Risiko

Realisierungsrisiko? Schadenhöhe

bei Misserfolg?

Klein

Mittel

Hoch, kann Unternehmen

gefährden

Planbarkeit

Wie genau ist der Ablauf, sind die

Teilschritte planbar?

Gut, klar

Mittel, schwierig

Schlecht, fast nicht planbar

Motivation

Bereitschaft zum Projekt bei Auf-

traggeber und Mitarbeitern

Gut, wenig Konﬂikte zu

erwarten

Unterschiedlich, braucht Auf-

merksamkeit der Führung

Kritisch, Krisen und Wider-

stand zu erwarten

Einleitung

Tab. 1.3 Organisationsformen und Projektcharakteristik

Prozess-

Eigenschaften

Wiederholte

Durchführung

Einmalige Durchführung

Geringe Komple-

xität

Geringe bis mitt-

lere Komplexität

Mittlere bis hohe

Komplexität

Hohe bis sehr

hohe Komplexität

Kurz-/mittel-

fristig

Kurzfristig

Kurz-/mittel-

fristig

Organisations-

form

Laufendes Ge-

schäft:

permanente Pro-

zess-Organisation

Sonderaufgabe:

temporär beauf-

tragte Person

oder Arbeits-

gruppe

Projekt:

temporäre Pro-

jektorganisation

Programm:

temporäre

Programm-

organisation

1.2.3

Projektwürdigkeit

Viele Unternehmen und Verwaltungen haben Entscheidungshilfen in Form eines Bewer-

tungsschemas gemäß Tab. 1.2 entwickelt. Mit einem solchen können sie beurteilen, ob für

ein Vorhaben die Projektwürdigkeit erreicht ist oder nicht. Auch teilen sie ihre Projekte in

unterschiedliche Kategorien ein, je nach Komplexität und strategischer Bedeutung für das

Unternehmen.

Aufgrund der Einschätzungen der Kriterien muss für oder gegen die Projektwürdigkeit

des Vorhabens argumentiert und die entsprechende Einschätzung gewählt werden. Wird

ca. 40 % der Gesamtpunktzahl (14 von 36 Punkten) erreicht, so sollte ein Projekt und

ein entsprechendes Vorgehen genauer geprüft werden. Je nachdem, welche Kriterien eine

hohe Einstufung haben, kann die temporäre Projektorganisation unterschiedliche Formen

annehmen.

Tab. 1.3 zeigt eine einfache Methode zur Ableitung der Organisationsform aus

verschiedenen Projektcharakteristika. Entsprechend den Projektkategorien werden un-

terschiedliche Anforderungen an die Person des Projektleiters gestellt.

1.2.4

Klassifizierung von Projekten

In einem Unternehmen sind die anfallenden Projekte unterschiedlich groß und komplex

und werden auf unterschiedlichen Ebenen abgewickelt. So brauchen strategisch und poli-

tisch brisante Projekte die volle Aufmerksamkeit des Top Managements, während ope-

rative Projekte in den entsprechenden Bereichen abgewickelt und entschieden werden

können. Bei umfangreichen und hochkomplexen Projekten ist auch die Projektorgani-

sation entsprechend ausgebildet, bei kleinen und weniger komplexen Projekten ist sie

entsprechend schlank. Die Beurteilung und Zuordnung der Projekte kann natürlich situa-

tiv vollzogen werden. In großen Organisationen empﬁehlt es sich aber, eine Systematik

1.2

Was sind Projekte?

einzuführen. Dies nicht nur, um die Zuordnung zu vereinheitlichen, sondern auch, um

die Sensibilität der Bedeutung und Komplexität zu entwickeln und das Projektverfahren

entsprechend zu wählen.

Im folgenden Beispiel einer Stadtverwaltung werden drei Projektklassen unterschie-

den:

Projektklasse A:

Umfangreiche, hochkomplexe Projekte mit hoher strategischer und politischer Bedeu-

tung

Auftraggeber und Entscheider ist das Top-Management (Mitglieder der Exekutivbe-

hörde)

Die Projektorganisation weist in der Regel eine Steuergruppe auf

Alle Phasen gemäß Richtlinien des Projektmanagement-Handbuches sind zu durchlau-

fen

Tab. 1.4 Beispiel einer Bewertungstabelle einer Stadtverwaltung

Kriterium

Teilkriterium

Ge-

wicht

Nicht ausge-

prägt 1 Punkt

Mittel aus-

geprägt

3 Punkte

Sehr aus-

geprägt

5 Punkte

Bewertung

Punk-

te × Ge-

wicht

Größe,

Umfang

Investitions-

summe

Weniger als

C 25.000

C 25.000 bis

250.000

Über

C 250.000

Interner Per-

sonalaufwand

Weniger als

20 Personen-

tage (PT)

20–60 PT

Über 60 PT

Projektdauer

Weniger als

6 Monate

1/2 bis 1 Jahr

Über 1 Jahr

Komplexität Soziale und

politische

Komplexität

Keine Interes-

senkonﬂikte

Einige Inter-

essenkonﬂikte

Große

Interes-

senkonﬂikte

Inhaltliche

Komplexität

Hoher Be-

kanntheitsgrad

Anspruchs-

voll,

bereichs-

übergreifend

Sehr an-

spruchsvoll,

hoher

Neuig-

keitsgehalt

Bedeutung

Strategische

Bedeutung

Gering

Mittel

Hoch

Zuweisung der

Kategorien

08 bis 19 Punkte: Kat. C

20 bis 29 Punkte: Kat. B

30 bis 40 Punkte: Kat. A

Total

Punkte

Kategorie

PT Personentage

Einleitung

Projektklasse B:

Komplexe Projekte, jedoch ohne strategische oder politische Brisanz

Auftraggeber und Entscheider sind das mittlere Management (Geschäftsfeld-Lei-

ter/Mitglied der Exekutivbehörde)

Projektorganisation entspricht je nach Umfang entweder der Klasse A oder C

Projektklasse C:

Kleinere, weniger komplexe Projekte

Auftraggeber und Entscheider sind das mittlere Management (Abteilungsleiter)

Einfache Projektorganisation, keine Steuergruppe

Phasen können zusammengefasst werden

Falls C-Projekte weitgehend durch eine Person bearbeitet werden können, sind sie als

Sonderaufträge einzustufen

Um die Projekte zu klassiﬁzieren, wurde in Tab. 1.4 eine entsprechende Bewertungsta-

belle erarbeitet. Daraus kann resultieren, dass ein umfangreiches, teures Projekt durchaus

Unternehmen

Unterzeichnung

= Projekt-Auftrag

Idee, Verbesserungsvor-

schlag = Projekt-Antrag C

Projektauftrag

Geschäftsleitung

externer Auftrag

Offerte

Vertragsverhandlungen

externer Kunde

Mitarbeiter

Offertanfrage

Abb. 1.3 Entstehung von Projekten

1.2

Was sind Projekte?

der Kategorie B, ein kleineres, aber politisch brisantes Projekt der Kategorie A zugeordnet

werden kann.

Die Anzahl der Klassen und deren Charakterisierung, die Kriterien, die Gewichtungen

und Zuordnungen der Punkte müssen in jedem Fall betriebsspeziﬁsch erarbeitet werden.

1.2.5

Entstehung von Projekten

Projekte können wie in Abb. 1.3 dargestellt auf unterschiedliche Arten entstehen.

Abhängig davon, wie das Projekt entstanden ist (internes Projekt oder Kundenprojekt),

welche Vorgeschichte es hat, um welche Projektart oder um welche Projektausprägung es

sich handelt, muss der Projektleiter sein Vorgehen anpassen. Diese Punkte haben einen

direkten Einﬂuss auf die Auswahl der Prozesse und Werkzeuge, wie folgende Beispiele in

Tab. 1.5 zeigen.

Tab. 1.5 Verschiedene Projektarten und -Ausprägungen erfordern unterschiedliche Vorgehenswei-

sen

Auftrags-

abwicklungs-

projekt

Ein externer Kunde hat ein Problem. Das Unternehmen hat dem Kunden ein

verbindliches Angebot gemacht. Termin und Kosten sind ﬁxiert und rechtlich

verbindlich, vielleicht wurde Konventionalstrafe vereinbart. Der Projektleiter

legt den Schwerpunkt auf bewährte standardisierte Prozesse, auf eine risikoar-

me und termintreue Abwicklung sowie eine wirksame Kostenkontrolle

Internes

Entwicklungs-

projekt auf

eigenes Risiko

Die Geschäftsleitung hat ein strategisches Projekt initialisiert zur Neuausrich-

tung des Unternehmens. Zielgrößen und Termine sind nicht in Stein gemeißelt.

Bei neuen Erkenntnissen können Ziele, Termine oder Kosten durchaus disku-

tiert und angepasst werden

Verbesserungs-

vorschlag/Idee

der eigenen

Mitarbeiter

Die Motivation und das Wissen sind gegeben. Der Vorgesetzte muss den Mitar-

beitern den Rücken freihalten, dass sie über genügend Ressourcen verfügen, um

das Projekt neben allen Routineaufgaben efﬁzient bearbeiten zu können

Kleinprojekt

Einzelne Phasen oder Tätigkeiten können übersprungen werden. Der Projektlei-

ter arbeitet nach dem Standard-Prozess, beschließt bei Projektbeginn, einzelne

Schritte und Reviews zu überspringen. Er hält dies in der Projektdokumentation

fest

Akzeptanz-

projekt

Wenn bei einem Projekt große Widerstände zu erwarten sind, wird der Pro-

jektleiter alle relevanten Stakeholder frühzeitig einbinden und ein sorgfältig

abgestimmtes Informations- und Kommunikationskonzept erstellen

Innovations-

projekt/Pionier-

projekt

Das Unternehmen ist mit seiner Produktlinie an die Grenzen gestoßen und muss

auf eine völlig neue Technologie in der Herstellung setzen. Der Projektleiter

wird eine ausgewogene Mischung von Visionären und erfahrenen Spezialisten

einsetzen und diese in selbstorganisierten Teams arbeiten lassen

Einleitung

1.3

Was ist Projektmanagement?

Jedes Unternehmen will strategische und operative Ziele erreichen.

Die gesetzten Ziele können nicht immer über das Linienmanagement erreicht werden.

Abhängig von der Situation ist es sinnvoll, Vorhaben und Maßnahmen als Projekt anzu-

gehen und umzusetzen. Dies ermöglicht die Bündelung und Fokussierung von Kräften.

Bezüglich der Führung von Projekten verfolgen die klassische und agile Vorgehenswiese

unterschiedliche Ansätze.

In der klassischen Vorgehensweise haben sich folgende Elemente sehr bewährt:

Vorgehen in Phasen und als Arbeitspakete strukturieren

Entscheidungs-, Führungs- und Fachkompetenz pro Phase neu festlegen

In der agilen Vorgehensweise setzt man den Schwerpunkt der Elemente etwas anders:

Ermächtigte, selbstorganisierte Teams, welche sich laufend überprüfen und anpassen

Timebox-Verfahren mit frühen und häuﬁgen Lieferungen

Projektmanagement wird als Oberbegriff für alle planenden, überwachenden, koordi-

nierenden und steuernden Maßnahmen verstanden, die für die Um- oder Neugestaltung

von Systemen oder Prozessen bzw. Problemlösungen erforderlich sind. Das Vorgehen zum

Erreichen der Lösung, die dazu erforderlichen Mittel, deren Einsatz und Koordination sind

bedeutender als die Lösung selbst. Im Unterschied zum Projektmanagement hat das Lini-

enmanagement eher das so genannte laufende Geschäft sowie die Führung der beteiligten

Organisationen zur Aufgabe.

1.3.1

Hierarchien im Projektmanagement

Die Methode „Projektmanagement“ durchdringt die gesamte Organisation. Abb. 1.4 zeigt

die unterschiedlichen Aufgaben, welche durch unterschiedliche hierarchische Ebenen im

Unternehmen wahrgenommen werden.

Unter Programmmanagement wird im Zusammenhang mit Projektmanagement das

Management der Gesamtheit aller Projekte verstanden, die auf ein gemeinsames strate-

gisches Ziel ausgerichtet sind und untereinander Abhängigkeiten aufweisen. Es kann auf

unterschiedlichen Ebenen eines Unternehmens angesiedelt werden und nur eine Teilmen-

ge (z. B. Entwicklungsprojekte) oder die Gesamtheit aller Projekte eines Unternehmens

einschließen. Ein Programm ist wie ein Projekt zeitlich begrenzt und dauert so lange, bis

das Programmziel erreicht ist.

Im Programmmanagement geht es darum, verschiedene voneinander abhängige Projek-

te zu koordinieren, die Prioritäten abzustimmen und alle Ressourcen wie Arbeitsleistun-

gen und Finanzen entsprechend zuzuweisen. Beispiele: Forschungsprogramm, Entwick-

lungsprogramm usw.

1.3

Was ist Projektmanagement?

Programm-Management

Priorisierung

Ressourcen-Management

Lenkungs-Ausschuss

Projekt-Management

Projekt-Controlling

Führungskräfte

Mitarbeiter

Abb. 1.4 Projektmanagement-Aufgaben in der Unternehmenshierarchie

Ein Projektportfolio besteht aus Projekten und/oder Programmen eines Unternehmens

oder eines Unternehmensbereichs. Sie müssen nicht zwingend miteinander in Beziehung

stehen, greifen jedoch auf den gleichen Ressourcenpool zu, meistens auf Mitarbeiter und

Finanzen. Es geht darum, die Ressourcen der Organisation optimal zu nutzen und die stra-

tegischen Ziele der Organisation bei gleichzeitiger Minimierung von Risiken zu erreichen.

Produktmanagement umfasst alle strategischen und operativen Aktivitäten einer Stel-

le oder einer Person, die für ein Produkt oder eine Dienstleistung in allen Unternehmens-

bereichen verantwortlich ist. Diese Stelle ist meist auch Ansprechpartner für die Kunden.

Entwicklungen, Einführung oder Problembehebungen im Zusammenhang mit diesem Pro-

dukt können sehr wohl wiederum als Projekte abgewickelt werden.

1.3.2

Dimensionen im Projektmanagement

Die Dimensionen im Projektmanagement lassen sich gut anhand des IPMA „Eye of Com-

petence“ (siehe Abb. 1.5) strukturieren.

Einleitung

People

Practice

Perspective

Practice

Abb. 1.5 Eye of Competence von IPMA. (International Projectmanagement Association)

1.3.2.1

Kompetenzbereich Kontext (Perspective)

Dieser Kompetenzbereich befasst sich mit dem Kontext eines Projektes. Er enthält folgen-

de Themen:

Strategie

Governance, Strukturen und Prozesse

Compliance, Standards und Regulationen

Macht und Interessen

Kultur und Werte

Diese Themen setzen die Rahmenbedingungen und geben das Umfeld vor, in welchem

das Projekt abgewickelt wird. Im vorliegenden Handbuch Projektmanagement werden die-

se Themen an unterschiedlichen Stellen angesprochen und vertieft.

1.3.2.2

Kompetenzbereich Menschen (People)

Dieser Kompetenzbereich befasst sich mit den persönlichen und sozialen Kompetenzen.

Er enthält folgende Themen:

1.3

Was ist Projektmanagement?

Selbstreﬂexion und Selbstmanagement

Integrität und Verlässlichkeit

Persönliche Kommunikation

Beziehungen und Engagement

Führung

Teamarbeit

Konﬂikte und Krisen

Einfallsreichtum

Verhandlungen

Ergebnisorientierung

In diesem Kompetenzbereich liegt ein zentraler Schlüssel für den Projekterfolg. Ein

Projekt ist erfolgreich, wenn es gelingt, die Beziehungen der Menschen und Teams unter-

einander konstruktiv und positiv zu gestalten. Im vorliegenden Handbuch Projektmanage-

ment werden diese Themen im Kap. 3 Mensch und im Kap. 4 Team vertieft.

1.3.2.3

Kompetenzbereich Praktiken (Practice)

Dieser Kompetenzbereich befasst sich mit den Methoden und dem Handwerk des Projekt-

managements. Er enthält folgende Themen:

Projektdesign

Anforderungen und Ziele

Leistungsumfang und Lieferobjekte

Ablauf und Termine

Organisation, Information und Dokumentation

Qualität

Kosten und Finanzierung

Ressourcen

Beschaffung

Planung und Steuerung

Chancen und Risiken

Stakeholder

Change und Transformation

Um ein Projekt erfolgreich zu meistern, ist das Beherrschen des Handwerks eine unab-

dingbare Voraussetzung. Der entscheidende Faktor für den Projekterfolg liegt jedoch oft

im Faktor „wie gelingt es, die Beziehungen zwischen Menschen und Teams“ zu gestalten.

Im vorliegenden Handbuch Projektmanagement werden diese Themen hauptsächlich im

Kap. 2 Methodik vertieft.

Einleitung

1.3.3

Vorgehensprinzipien

Folgende Vorgehensprinzipien bzw. Denkhaltungen haben sich in der Praxis bewährt:

Vom Groben zum Detail

Variantenbildung

Phasengliederung

Problemlösungsprozess

Nachfolgend werden die Prinzipien „vom Groben zum Detail“ und „Variantenbildung“

erläutert. Die zwei anderen Grundsätze (Phasengliederung Abschn. 1.4.2 und Problemlö-

sung Abschn. 2.3.15) sind für das Projektmanagement derart zentral, dass sie gesondert

behandelt werden.

1.3.3.1

Vom Groben zum Detail

Das in Abb. 1.6 dargestellte Prinzip „vom Groben ins Detail“ ist eine zentrale Grundhal-

tung bei der Abwicklung eines Projektes. Es wird wie folgt umschrieben: Zu Beginn des

Projekts soll das Betrachtungsfeld weit gefasst und anschließend schrittweise fokussiert

Vorgehen vom Groben zum Detail

Ebene A

Ebene B

Ebene C

Unter

suchu

ngsb

ereich

Ges

taltu

ngs

bere

ich

Abb. 1.6 Vorgehen „Vom Groben zum Detail“

1.3

Was ist Projektmanagement?

werden. Dies betrifft sowohl die Untersuchung des Problemfeldes wie den Entwurf von

Lösungen.

Erst wenn das Problemfeld grob strukturiert, in sein Umfeld eingebettet und abgegrenzt

ist, bzw. Schnittstellen/Nahtstellen zum Umfeld deﬁniert sind, kann mit detaillierten Er-

hebungen begonnen werden.

Bei der Gestaltung der Lösung sind zuerst generelle Ziele und ein genereller Lösungs-

rahmen festzulegen. Deren Detaillierungs- und Konkretisierungsgrad ist im Laufe des

Projekts schrittweise zu vertiefen.

Zum Prinzip „Top-down“ ist die Umkehrung „Bottom-up“ denkbar. Der Ansatz von

unten nach oben kann unter speziellen Bedingungen durchaus sinnvoll sein, z. B. bei Ver-

besserungen in vorhandenen, funktionierenden Lösungen, bei so genanntem empirischen

Vorgehen. Bei konzeptionellem Vorgehen, also bei Neu- oder Umgestaltungen größeren

Ausmaßes ist es meist wirkungsvoller, vom Groben her ein Gesamtkonzept zu entwickeln,

damit ein Orientierungsrahmen für die durchzuführenden Teilschritte entsteht.

In der Umsetzung zeigt es sich sowieso, dass ein zirkuläres Vorgehen von „Top-down“

und „Bottom-up“ zu der nötigen, gemeinsamen Sicht führt. Dieses Abstimmen erhöht

auch wesentlich die Verbindlichkeit der einzelnen Personen, für eine so erstellte Struktu-

rierung oder Planung die Verantwortung mit zu übernehmen.

Lösungs-

prinzipien

Konzept-

varianten

Detail-

varianten

Problem:

Auto schrottreif

Spontane Idee:

Neues Auto

weiss

blau

rot

Abb. 1.7 Beispiel für eine stufenweise Variantenbildung

Einleitung

1.3.3.2

Variantenbildung

Das in Abb. 1.7 aufgezeigte Prinzip der Variantenbildung, des Denkens in Alternativen,

ist ein unverzichtbarer Bestandteil guter Planung. Es ist eine methodische Grundhaltung

und funktioniert bei Beachtung des Prinzips „vom Groben zum Detail“ ohne nennens-

werten zusätzlichen Planungsaufwand. Wird dieses Prinzip nicht beachtet, besteht ein

größeres Risiko, dass grundsätzlich andere Lösungsansätze erst in einem fortgeschritte-

nen Planungsstadium in die Diskussion eingebracht werden.

1.4

Vorgehensmodelle in Projekten

Ja nach Projektart, Größe und Komplexität des Projektes und den gegebenen Rahmenbe-

dingungen eignen sich unterschiedliche Vorgehensmodelle.

Die agilen Methoden kommen in der Softwareentwicklung und in anderen Branchen

wie beispielsweise Anlagenbau oder Produktentwicklung oft zum Einsatz.

Weit verbreitet ist die klassische, sequenzielle Phasenanordnung („Wasserfall-Mo-

dell“).

Im hybriden Projektmanagement werden klassische und agile Ansätze gemeinsam

angewendet. Das Projekt wird gegenüber Kunden klassisch geführt. Nach Innen wer-

den Teile wie beispielsweise die Entwicklung agil abgewickelt.

Jedes Vorgehensmodell hat seine Vorteile und Nachteile. Wichtig ist es, für die jewei-

lige Situation das beste Vorgehensmodell auszuwählen und anzuwenden.

Im vorliegenden Handbuch Projektmanagement werden die klassische und agile Vorge-

hensweise nicht getrennt behandelt. Im Sinne des hybriden Projektmanagements werden

die Elemente der klassischen und der agilen Vorgehensweise anhand der Phasen des klas-

sischen Projektmanagements (Projektbeauftragung, Initialisierung, Konzept, Realisierung

und Einführung) erklärt und vertieft.

Als Orientierung werden im Buch folgende Symbole verwendet:

Steht für die agile Vorgehensweise.

Steht für die klassische Vorgehensweise.

1.4.1

Agile Vorgehensweise

Klassische, traditionelle Vorgehensweisen haben wesentliche Beiträge im Projektmanage-

ment geleistet und leisten diese weiterhin. In der Produkt- und Softwareentwicklung hat

sich jedoch gezeigt, dass viele Projekte, welche mit einer Wasserfallmethode gemanagt

wurden, nicht die gewünschten Resultate brachten oder sogar scheiterten. Die Gründe

1.4

Vorgehensmodelle in Projekten

liegen in komplexen Aufgabenstellungen, schnelleren Arbeitswelten und stetigen Verän-

derungen. Diesen Umständen können agile Methoden wie Scrum, Large Scale Scrum

(LeSS), Extreme Programming, Kanban oder Scaled Agile Framework (SAFe®) entge-

genwirken.

Agile Methoden helfen auch, in möglichst kurzer Zeit eine kunden- bzw. anwenderspe-

ziﬁsche und funktionierende Software zu realisieren, ohne dass die genauen Anforderun-

gen im Detail bereits am Anfang festgelegt sein müssen. Agiles Projektmanagement heißt

bewegliches, ﬂinkes, prozess-orientiertes, reﬂexives, lernendes Vorgehen. Seine Grund-

sätze wurden im Manifesto for Agile Software Development (Beck et al. 2001, www.

agilemanifesto.org) festgelegt:

Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge

Funktionierende Software ist wichtiger als umfangreiche Dokumentation

Kooperation mit Projektbetroffenen ist wichtiger als Vertragsverhandlungen

Reaktion auf Änderungen ist wichtiger als Festhalten an einem starren Plan

Das agile Manifest folgt den folgenden 12 Prinzipien:

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Ausliefe-

rung wertvoller Software zufrieden zu stellen.

Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile

Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.

Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate

und bevorzuge dabei die kürzere Zeitspanne.

Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbei-

ten.

Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unter-

stützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.

Die efﬁzienteste und effektivste Methode, Informationen an und innerhalb eines Ent-

wicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.

Funktionierende Software ist das wichtigste Fortschrittsmaß.

Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und

Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.

Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.

Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.

Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorgani-

sierte Teams.

In regelmäßigen Abständen reﬂektiert das Team, wie es effektiver werden kann und

passt sein Verhalten entsprechend an.

Einleitung

Sprint 1

Sprint 2

Startphase

Product

Backlog

•

Release-

plan

Sprint

Backlog

Sprint

Backlog

Product

Increment

Product

Increment

•

Sprint 3

Sprint

Backlog

•

…

Zeit

Abb. 1.8 Schematische Darstellung des agilen Vorgehens nach SCRUM

Die Grundsätze und Prinzipen des agilen Manifests lassen sich auch auf Bereiche au-

ßerhalb der Softwareentwicklung anwenden.

Bei der agilen Vorgehensweise werden die Dimensionen Zeit und Budget ﬁx festgelegt,

das Ergebnis/der Scope ist ﬂexibel. In der klassischen Vorgehensweise ist in der Regel der

Scope ﬁx deﬁniert, und die Dimensionen Zeit und Budget werden ﬂexibel gehandhabt.

Dies ist ein Grundsatz, der in Projekten oft zu Zeitverzögerungen und Budgetüberschrei-

tungen führt.

Im vorliegenden Handbuch Projektmanagement wird Scrum als agiles Vorgehensmo-

dell vertieft ausgeleuchtet.

1.4.1.1

Scrum

Scrum wurde am Anfang sehr stark von den schlanken und innovativen Wegen in der

Produktenwicklung in Japan beeinﬂusst (Lean Management). Scrum besteht aus weni-

gen Regeln. Abb. 1.8 zeigt schematisch die Vorgehensweise nach Scrum auf. Nach der

Startphase (Initialisierung und Produktkonzeption) folgen die Iterationen bzw. Sprints

in vorgeplanten Zeitabständen (Timeboxes). Die vereinbarten Teilaufträge werden von

Teams bearbeitet, die weitgehend selbstverantwortlich handeln und sich selbst organisie-

ren.

1.4

Vorgehensmodelle in Projekten

Grundprinzip dieser Ausprägungen sind die relativ kurzen und zum Voraus festgelegten

Iterationszyklen (Timeboxes), innerhalb derer hoch motivierte Teams eigenverantwortlich

Lösungen (Inkremente) entwickeln und testen. Dabei ﬂießen die Lernerfahrungen oder

neue Anwender-Erkenntnisse in den nächsten Zyklus ein.

In Scrum gibt es die drei Rollen: Product Owner, Team und Scrum Master. Die Rolle

des klassischen Projektleiters gibt es nicht, resp. wird auf die beiden Rollen Product Ow-

ner (fachliche und inhaltliche Steuerung) und den Scrum Master (Methodenspezialist, der

allfällige Hürden beseitigt) aufgeteilt.

Die Anforderungen werden in einem priorisierten Product Backlog festgehalten. Der

Inhalt und die Priorisierung dieses Product Backlogs ändert sich während des Projektes

laufend. Dadurch kann einfach und ﬂexibel auf Änderungen eingegangen werden. Es ist

der Product Owner, der über den Product Backlog waltet und die Priorisierung bestimmt.

Scrum ist ein empirischer Prozess, der dem Credo von „inspect and adapt“ folgt. Das

heißt das erreichte Ergebnis (Inkrement) und die Arbeitsweise werden im Sprint Review

regelmäßig begutachtet und in der Retrospektive verbessert. Dadurch ist eine kontinuier-

liche Verbesserung sichergestellt.

Ein Sprint wird so geplant, dass am Ende ein Inkrement entsteht, welches einen Mehr-

wert darstellt und funktionsfähig ist. Dieser Fokus auf das Liefern eines Mehrwerts verhin-

dert, dass man sich mit Nebensächlichkeiten oder unwichtigen Dingen beschäftigt. In der

Sprintplanung gibt der Product Owner seine Prioritäten, Wünsche und das Sprintziel vor.

Letztendlich entscheidet aber das Team nach dem Ziehprinzip (pull) über den effektiven

Inhalt des Sprints. Dies fördert die Eigenverantwortung und Selbstorganisation. Zusätz-

lich wird durch das Ziehsystem eine systematische Überlastung des Teams vermieden. Es

empﬁehlt sich auch, Probleme und Hindernisse frühzeitig zu erkennen und zu adressie-

ren. Gerade in den ersten Sprints sollen die Knacknüsse angegangen und zu einer Lösung

geführt werden.

Scrum ist harte Arbeit. Es müssen neue Spielregeln gelernt, alte Gewohnheiten abge-

legt, Hindernisse bewältigt und Probleme gelöst werden. Scrum erfolgreich anzuwenden

ist ein ständiger Lernprozess, welcher auch Zeit und Geduld fordert. Es ist die zentra-

le Aufgabe des Scrum Masters, das Team und den Product Owner bei der Bewältigung

dieser Herausforderungen zu unterstützen und Scrum erfolgreich anzuwenden.

Das Phasenkonzept kann in einer adaptierten Form auch für Scrum angewendet wer-

den. In der Startphase eines Scrum-Projektes ist es zentral, dass zuerst ein Produktkonzept

erarbeitet wird. Damit wird die Idee konkretisiert. Das Produktkonzept beschreibt den

Nutzen für den zukünftigen Anwender des Produktes oder Services und die wesentlichen

Leistungsmerkmale. Weiter müssen in der Startphase der initiale Product Backlog und der

Release-Plan erstellt werden.

Agile Vorgehensweisen haben sich in komplexen Bereichen als ﬂexibler, schneller und

ökonomischer bewährt als das planungsorientierte Projektmanagement.

Einleitung

1.4.1.2

Kanban

Kanban hat seinen Ursprung Mitte des 20. Jahrhunderts bei Toyota. Kanban wurde als

Methode zur Flexibilisierung und Efﬁzienzsteigerung in der Produktion entwickelt. Die

Übertragung der Ideen von Kanban auf das Management von Projekten wurde später von

David J. Anderson vorgenommen.

Kanban gibt keine Abläufe oder Strukturen vor. Kanban fördert wie Scrum die Selbst-

organisation, indem die Mitarbeiter oder das Team die Aufgaben selbständig an sich

ziehen (Pull Prinzip). Kanban basiert auf vier Grundprinzipien und sechs Praktiken.

Die vier Grundprinzipien von Kanban lauten:

Starte mit dem, was Du gerade machst.

Strebe inkrementelle, evolutionäre Veränderungen an.

Respektiere aktuelle Prozesse, Rollen, Verantwortlichkeiten und Titel.

Fördere Führung und Verantwortung auf allen Ebenen der Organisation.

Die sechs Praktiken von Kanban lauten:

Mache die Arbeit sichtbar (Kanban Board siehe Abschn. 2.5.2).

Limitiere die Menge angefangener Arbeiten.

Messe und manage den Fluss.

Mache Prozessregeln explizit: eindeutig und bekannt.

Entwickle Rückmeldemechanismen.

Führe gemeinschaftlich Verbesserungen durch.

Die Prinzipien von Kanban können gut mit anderen agilen Methoden wie Scrum oder

der klassischen Vorgehensweise im Projektmanagement kombiniert werden.

1.4.2

Klassische Vorgehensweise: Phasenkonzept

Die Prinzipien „vom Groben zum Detail“ und „Variantenbildung“ bedeuten für die Be-

arbeitung von Problemen folgendes: Idee, Entwicklung, Umsetzungsplanung und Reali-

sierung einer Lösung sind in einzelne Arbeitspakete und diese wiederum in Phasen zu

unterteilen, die logisch und zeitlich voneinander getrennt werden können. Dies hat den

Zweck, den Werdegang einer Lösung in überschaubare Etappen zu gliedern. Damit wird

ein abgestufter Planungs-, Entscheidungs- und Konkretisierungsprozess mit vordeﬁnier-

ten Meilensteinen bzw. Korrekturpunkten ermöglicht.

In der Abb. 1.9 wird das Phasenmodell in seiner einfachsten, idealtypischen Form be-

schrieben.

1.4

Vorgehensmodelle in Projekten

Einführung

Konzept

Realisierung

Initialisierung

Beauftragung

Meilenstein: Grösse des Rhombus‘ als Mass für die Wahrscheinlichkeit eines Projektabbruchs

Projektabbruch

Abb. 1.9 Das ideale Phasenkonzept

Anzahl Projektphasen

Die Anzahl Projektphasen und auch der Formalismus, mit dem sie abgewickelt werden,

sind erheblich von Art, Umfang, Risiko und Bedeutung eines Projektes sowie auch von

der gewünschten Einﬂussnahme des Auftraggebers abhängig.

Kleinere Projekte können mit einer geringeren Anzahl Phasen und mit weniger Forma-

lismus erledigt werden. Andererseits sind gegenüber dem theoretischen Modell Phasen-

erweiterungen denkbar, z. B. durch Vorschalten einer Feasibility Study (Vorstudie), mit

einer Prototypphase, einer Test- und einer Abnahmephase.

Die Darstellung als Blockdiagramm oder als „Wasserfallmodell“ und die Bezeichnung

der Phasen sind von sekundärer Bedeutung, da sie von der Branche, der Aufgabenstellung

und den im Unternehmen verwendeten Begriffen beeinﬂusst werden. Einige gebräuch-

liche Phasenmodelle sind in Abb. 1.10 aufgeführt. Entscheidend ist, dass in Entschei-

dungssitzungen zwischen den Etappen die Komplexität einer Problemstellung und das

Risiko einer Fehlentscheidung durch die gezielte Gliederung der Arbeitspakete in einzel-

ne Planungs- und Realisierungsetappen reduziert werden können.

Einleitung

1 Vorprojekt

2 Hauptprojekt

3 Detailprojekt

4 Systembau

5 Einführung

nach Systems

Engineering

1 Vorprojekt

2 Entwicklung

3 Produktions-

vorbereitung

4 Null/Pilotserie

5 Serien-

produktion

Produktentwick-

lungs-Projekte

1 Strategische Planung

4 Ausschreibung

2 Vorstudien

2.1 Machbarkeit

2.2 Auswahlverfahren

6 Bewirtschaftung

6.1 Betrieb

6.2 Erhaltung

3 Projektierung

3.1 Vorprojekt

3.2 Bauprojekt

3.3 Bewilligungsverfahren

5 Realisierung

5.1 Ausführungsplanung

5.2 Ausführung

5.3 Inbetriebnahme

Bauprojekte SIA

1 Initialisierung

2 Grobkonzept

3 Sprints

iterative

Programmierung

Einführung und Abnahme

IT-Projekt mit Scrum

Abb. 1.10 Phasenmodelle und Phasenbezeichnungen

1.4.2.1

Die Phase der Projektbeauftragung

Diese meist eher unstrukturierte Phase umfasst die Zeitspanne zwischen dem Erkennen

des Problems und dem Entschluss, etwas Konkretes zu unternehmen. Die Problemstel-

lung kann dabei entweder bereits konkret formuliert sein oder aber lediglich aus vagen

Vermutungen hervorgehen. Dabei ist es unwesentlich, woher der Anstoß für die Um- oder

Neugestaltung kommt. Wichtig ist vielmehr, dass er von den für die Zuteilung der er-

forderlichen Mittel personeller, ﬁnanzieller, organisatorischer Art autorisierten Stellen

aufgenommen, akzeptiert und mit einer Projektvereinbarung freigegeben wird.

Die Vorarbeiten und Aktivitäten dieser ersten „Deﬁnitions-Phase“ resultieren idealer-

weise in einem Projektsteckbrief. Der Projektsteckbrief enthält Informationen zum strate-

gischen Bezug und zu dem erwarteten Mehrwert, einen ersten groben Terminplan und die

erwarteten Kosten. Er benennt die zentralen Projektrollen und dient zusammen mit dem

Business Case als Entscheidungsgrundlage, ob das Projekt bewilligt und in das Projekt-

portfolio aufgenommen wird.

1.4.2.2

Die Initialisierungsphase

Im Rahmen der Initialisierungsphase müssen verbindliche Aussagen zu Machbarkeit, Ri-

siken und Stakeholdern erarbeitet werden. Wesentliche Grundlagen dazu sind die Analyse

1.4

Vorgehensmodelle in Projekten

Relative Bedeutung

der Entscheide

Wissen

Projektkosten

Risiko

typ. Aufmerksamkeit

des Managements

Initialisierung

Konzept

Realisierung

Einführung

Zeit

klein

mittel

gross

Abb. 1.11 Einﬂussmöglichkeiten im Projekt

der aktuellen Situation sowie klar vereinbarte Ziele und die Formulierung der Anforde-

rungen an das Resultat des Projekts, z. B. an das zu entwickelnde Produkt.

Zu Projektbeginn ist das Wissen zum Projektinhalt und zu den Lösungen gering. Es

steigt mit dem Projektfortschritt. Umgekehrt sind die Risiken am Anfang am größten.

So ist es wünschenswert, diese so rasch und so weit wie möglich zu reduzieren. Ge-

hen die Ziele und Anforderungen an die Grenzen des Möglichen, oder ist das Mögliche

nur ungenau bekannt (Technologiegrenze, politisch heikle Ziele), so ist es sinnvoll, vor

der Durchführung des ganzen Projektes eine Vorstudie durchzuführen (ähnliche Begriffe:

Machbarkeitsstudie, Feasibility Study, Vorprojekt). Wenn sich zeigt, dass die Ziele mit

den eigenen Möglichkeiten nicht erreicht werden können, drängt sich schon bei diesem

Meilenstein ein Projektabbruch auf. So wird vermieden, dass wertvolle Ressourcen für

ein aussichtsloses Projekt eingesetzt werden.

Die Initialisierungsphase stellt auch aus organisationspsychologischer Sicht hohe An-

sprüche an Projektleitung und Auftraggeber. Abb. 1.11 verdeutlicht dies. Wesentliche

Entscheidungen sind zu einem Zeitpunkt zu fällen, an dem weder genügend Wissen noch

Erfahrung in der Zusammenarbeit zur konkreten Fragestellung vorhanden sind.

Einleitung

In dieser Phase wird der Projektauftrag verfasst. Darin sind die Ziele und die Rahmen-

bedingungen für das Projekt festgehalten. Folgende Themenblöcke werden erarbeitet und

im Auftrag ﬁxiert:

Anforderungen aufnehmen: Was soll realisiert werden?

Projektorganisation festlegen

Stakeholder identiﬁzieren und analysieren

Risiken identiﬁzieren und Maßnahmen zur Reduktion der Risiken entwickeln

Projekt strukturieren und grob planen

Der Auftraggeber ist dafür verantwortlich, den Antrag in einen Projektauftrag überzu-

führen. Mit dem Projektauftrag werden die erforderlichen Ressourcen bereitgestellt. Aus

kommunikationspsychologischer Sicht delegiert der Auftraggeber die Ausarbeitung des

Projektantrages an den Projektleiter. Dieser führt zum Abschluss der Phase das Kick-Off-

Meeting durch.

Entscheidet man sich am Ende der Initialisierungsphase zum Abbruch des Projektes,

so bedeutet dies weder „Fehler“ noch Versagen, sondern eine bewusste Weichenstellung

aufgrund von erarbeiteten Erkenntnissen.

1.4.2.3

Die Konzeptphase

Der Sinn der Konzeptphase besteht im Entwickeln von Lösungsvarianten. In dieser Phase

sind die geplante Zielerreichung, Funktionstüchtigkeit, Zweckmäßigkeit und Wirtschaft-

lichkeit fundiert zu beurteilen. Die Aufmerksamkeit ist auf die Ausarbeitung von mögli-

chen Lösungsvarianten gerichtet.

Das Ergebnis der Konzeptphase ist die Entscheidung für eine Lösungsvariante. Für

die ausgewählte Variante werden ausführungsreife Pläne erstellt und Lösungskonzepte

erarbeitet, welche beschreiben, wie die Anforderungen umgesetzt werden.

Weiter gilt es, die gewählte Lösung im Detail zu planen und auszuarbeiten. Hier werden

oftmals Untersysteme bzw. einzelne Aspekte aus dem Gesamtsystem bearbeitet.

1.4.2.4

Die Realisierungsphase

In der Realisierungsphase werden die Pläne aus der Konzeptphase verwirklicht. Typische

Arbeiten der Realisierungsphase sind:

Anlagen und Geräte herstellen

Software abschließend erstellen

benutzerfreundliche Dokumentation bzw. Bedienungsanleitung erstellen

Organisatorische Regelungen im Falle von Störungen usw. festlegen

Wartungsorganisation, Instandhaltungskonzepte usw. festlegen

Tests durchführen

Oftmals werden hier auch einzelne Teilsysteme gebaut, die in die Gesamtlösung inte-

griert werden.

1.4

Vorgehensmodelle in Projekten

Ein umfassendes Projektcontrolling hilft, die Erreichung der gesetzten Ziele sicherzu-

stellen. Allfällige Änderungswünsche werden über den Change Request Prozess gesteuert

und zum Entscheid geführt.

1.4.2.5

Die Einführungsphase

Einführung

Nur relativ kleine und einfache Lösungen können ohne großes Risiko als Ganzes ein-

geführt werden. Bei großen und komplexen Systemen ist wegen der Vielzahl nicht kal-

kulierbarer Nebenerscheinungen und Abhängigkeiten eine schlagartige Einführung nicht

sinnvoll. Es empﬁehlt sich, stufenweise vorzugehen: Mit dem Gesamtkonzept im Visier

werden die weiteren Schritte von den ersten Erfahrungen mit der Einführung abhängig

gemacht.

In der Praxis entpuppt sich diese – oberﬂächlich gesehen – sehr technische Phase oft-

mals als sehr heikel und langwierig. Das Projektteam hat sich schon über längere Zeit mit

der Neuerung oder Veränderung, die das Projekt mit sich bringt, beschäftigt und merkt

gar nicht mehr, welche einschneidende Veränderung diese Einführung für alle übrigen

Personen mit sich bringt. Diese Ungleichzeitigkeit der beiden Systeme Projekt und Linie

erfordert wiederum eine gute Zusammenarbeit der Führungspersonen.

Übergabe

Der Erfolg einer Systemeinführung ist ebenfalls wesentlich davon abhängig, wie der

Know-how-Transfer greift. Das heißt, ob es gelingt, die Systembetreuer und die Anwen-

der oder Benutzer genügend schnell und umfassend zu schulen und zu informieren. Ziel

muss hier sein, dass sich das Entwicklungs- und das Realisierungsteam möglichst rasch

überﬂüssig machen.

Abschluss

Jedes Projekt kommt zu einem Ende. Selbst abgebrochene Projekte benötigen Abschluss-

arbeiten. Wird der Projektabschluss nicht bewusst vollzogen, so weiß niemand, ob das

Projekt abgeschlossen ist.

Für den Projektabschluss sind folgende Arbeiten durchzuführen:

Projektarbeit abschließen, d. h. mögliche Restarbeiten klar zuordnen und terminieren

oder in einen zukünftigen Release verschieben

Schlussabrechnung erstellen

Projektdokumentation vervollständigen und die Archivierung sicherstellen

Aufgaben, Kompetenzen und Verantwortung an die Anwender oder eine Betriebsorga-

nisation übergeben

Projektunterlagen der Betriebs- oder Wartungsorganisation abgeben

Projektabschluss mit dem Auftraggeber, um das „Projekt abzugeben“ und mit dem Pro-

jektteam, um dieses Team aufzulösen. In beiden Systemen kann es sinnvoll sein, eine

Einleitung

kritische Projektrückschau zu halten, einerseits um das Projekt loszulassen, aber vor al-

lem, weil erkannte Fehler eine grosse Lernchance im Sinne der lernenden Organisation

sind. Mögliche Fragen dabei können sein: Was ist gut gelaufen? Wo gab es Proble-

me? Konnte der geplante Aufwand (Personal, Kosten, Zeit) eingehalten werden? Was

könnte in Zukunft besser gemacht werden?

1.4.2.6

Die Nutzung

Wenn das Projekt abgeschlossen ist, beginnt die Phase der Nutzung. Nach der beim Pro-

jektabschluss bestimmten Zeitspanne ﬁndet eine Bewertung oder Kontrolle des Projekt-

ergebnisses statt. Je nach Art des Projektes werden Arbeiten in Garantie oder für eine

verbesserte Auﬂage der Lösung/einen neuen Release festgehalten. Meist wird hier eine

Wirksamkeitsüberprüfung/eine Projekt-Evaluation vorgenommen: Wie gut stimmen die

betriebswirtschaftlichen Prognosen?

1.4.3

Hybrides Projektmanagement

Immer weniger Projekte sind so ausgeprägt, dass für deren Management ausschließlich

das klassische oder agile Vorgehen geeignet ist. In der Praxis liegen sie meistens irgend-

wo dazwischen, so dass sich eine Kombination beider Projektmanagementphilosophien

aufdrängt (siehe Abb. 1.12). Am besten ist die Kombination dadurch möglich, dass aus-

gewählte Projektphasen oder Teilprojekte unterschiedlich abgewickelt werden. Beispiels-

weise kann in einem Produktentwicklungsprojekt, in dem zu Beginn die Anforderungen

erst grob bekannt sind, eine agile Phase eingeschaltet werden, um danach klassisch wei-

terzufahren. In einem komplexen Kundenprojekt mit Teilprojekten kann die Software-

Entwicklung mit Scrum vorteilhafter sein, während für die anderen Teilprojekte der klas-

sische Ansatz geeigneter ist.

Es ist auch möglich, im klassischen Vorgehen einzelne Komponenten wie tägliche

Standup-Meetings, Kanban Board oder Retrospektive aus dem agilen Vorgehen anzuwen-

den.

Das „Sowohl-als-auch“ stellt vom Projektmanagement her hohe Anforderungen an

die Flexibilität. Ist beim klassischen Projektmanagement der Fokus eher auf die ratio-

nalen Zusammenhänge, auf die Planung und auf die direkte Steuerung gerichtet, so stehen

beim agilen Vorgehen der evolutionäre und soziale Aspekt sowie die indirekte Steuerung

im Vordergrund. Beide Vorgehensweisen erfordern ein unterschiedliches Organisations-,

Rollen- und Führungsverständnis.

Einzelne Methoden können „hybridisiert“ werden. Doch hier gilt: nur gezielt und be-

wusst mischen, ansonsten droht die Verwässerung. Beispielsweise kann in einer klas-

sischen Projektsequenz bei parallelen Arbeitspaketen die Kanban-Methode angewendet

werden, da sie ﬂexibler und transparenter ist als Balkendiagramme.

1.4

Vorgehensmodelle in Projekten

Klassisch und agil abgewickelte Phasen

Klassisch und agil abgewickelte Teilprojekte

Aufbau Pro-

duktionslinie

Fertigungs-

planung

Realisierung

Konzeption

Initialisierung

Realisierung

Hardware I

Einführung

Konzeption

Realisierung

Hardware II

Realisierung

Software

agil

klassisch

Abb. 1.12 Klassische und agile Phasen bzw. Teilprojekte

1.4.4

Change-Projekte

Jedes Projekt bringt Veränderungen mit sich. Unter „Change-Projektmanagement“ lassen

sich alle Vorhaben subsumieren, welche radikale, umfassende und bereichsübergreifende

Veränderungen der Organisation zum Ziel haben. Dies kann sein: Einführung von neu-

en Prozessen, Fusionen, Umsetzung neuer Strategien usw. Mitlaufend werden dabei oft

auch neue Verhaltensweisen und Kulturen angestrebt, z. B. Kommunikationskultur, Feh-

lerkultur, usw. In Abgrenzung zu Change-Projekten schließen wir hier die „kontinuierliche

Verbesserung“ aus (KVP, KAIZEN).

Da in Change-Projekten die Eigenleistungen durch das handelnde System selber er-

bracht werden müssen, sind sie durch die Betroffenheit der Organisationsmitglieder ei-

nerseits und durch die oft selbstüberschätzende Herangehensweise andererseits besonders

heikel: Es müssen Verkrustungen aufgebrochen werden, und es muss mit Ängsten und

Widerständen, aber auch mit unrealistischen Erwartungen gerechnet werden. Für diese

Vorhaben orientiert man sich daher am Transformation-Management, welches die sozia-

len Prozesse nutzt, um die sachlichen Ziele zu erreichen.

Einleitung

Voraussetzung für ein Veränderungsprojekt ist ein gewisses vorhandenes Verände-

rungsbewusstsein, sonst sind die bewahrenden Kräfte zu stark. Eine Orientierung gibt die

Formel:

U V M > W

Wobei:

U = Unzufriedenheit mit dem Ist-Zustand

V = Vision, Attraktivität des Soll-Zustandes

M = Maßnahmen, Konkrete Umsetzungsschritte, erreichbare erste Erfolge

W = Widerstand gegen Veränderung, Energie zur Bewahrung des Bestehenden

Nach Doppler und Lauterburg (2014) sollen bei Veränderungsprojekten die folgenden

Schlüsselfaktoren beachtet werden:

Energie wecken und Vertrauen schaffen

In Prozessen statt in Strukturen denken

Das Unternehmen auf sein Umfeld ausrichten

Durch Kommunikation vernetzen

Von außen nach innen organisieren

Das Lernen sicherstellen

Wichtig bei Change-Projekten sind daher eine Vision, klare Ziele, transparente In-

formation und Kommunikation sowie ein Vorgehen in Prozessen, welches gemeinsames

Lernen und neue Erfahrungen ermöglicht. Eine mögliche Vorgehensweise in Anlehnung

an die obige Formel schlägt John P. Kotter (2012) vor (siehe Abb. 1.13).

Technokratische Modelle fokussieren sich sehr auf eine direkte Steuerung von Verän-

derungen. Selbst bei konsequenter Anwendung und Umsetzung in die Praxis greift dieser

Ansatz aber oft zu kurz: Die Organisation erweist sich als resistent; festsitzendes organi-

sationales Wissen lässt sich nur schwer verlernen, bestehende Mauern werden verteidigt.

Ganzheitliche Ansätze orientieren sich zusätzlich an systemischen Erkenntnissen. Sie

setzen auf die reﬂexiven Dynamiken der Organisation, welche – gezielt genutzt – weit

größere Hebelwirkungen für grundlegende Veränderungen erzielen können als die aus-

schließliche Zentrierung auf den Menschen. Damit richtet sich der Fokus auf die Ma-

kroebene, also auf die Arbeit am System statt auf die Arbeit im System, auf indirekte

Steuerung, auf Gestaltung des Projektkontextes und dessen Beziehung zur Welt der Linie.

Diese Voraussetzungen und Bedingungen stimulieren die Organisation dazu, sich in eine

bestimmte Richtung selbst zu verändern. Eine konsequente Idee dazu ist „WaVe – Wan-

del durch Vernetzung“, ein Verfahren, den Wandel durch vernetzte und selbstorganisierte

Teams zu inszenieren (Petersen et al. 2011).

Unternehmen und Organisationen, die einen Wandel ins Auge fassen, tun jedenfalls gut

daran, sich bewusst für einen Ansatz zu entscheiden und einen neutralen Außenstehenden

1.4

Vorgehensmodelle in Projekten

Eine Führungskoalition aufbauen

Vision und Strategie entwickeln

Die Vision des Wandels kommunizieren

Mitarbeiter auf breiter Basis befähigen

Schnelle Erfolge erzielen

Erfolge konsolidieren und Veränderungen einleiten

Neue Ansätze in der Kultur verankern

Wandel in Unternehmenskultur verankern

Einführung neuer

Verhaltensweisen

Auftauen des

verhärteten

Status quo

Ein Gefühl für die Dringlichkeit erzeugen

Abb. 1.13 Acht-Stufen-Modell nach Kotter

(bzw. ein außenstehendes System) als Berater oder Change Agent einzusetzen. Eine Or-

ganisation kann sich nur sehr schwer selber „aus dem Sumpf ziehen“. Nach dem Modell

der Komplementärberatung (Königswieser et al. 2008) kann dies auch ein Beratungsteam

sein, das aus einer Prozessberatung und einer Fachberatung zusammengesetzt ist, die sich

aber gegenseitig verstehen und zusammenarbeiten müssen.

1.4.5

Weitere Vorgehensmodelle

1.4.5.1

V-Modell

Das V-Modell ist ein weiteres sequentielles Vorgehensmodell. Das Vorgehen eignet sich

in Branchen und Gebieten mit hohen Ansprüchen an die Sicherheit, wie beispielsweise in

der Medizintechnik oder der Luftfahrt.

Auf dem linken Ast der Abb. 1.14 wird der Projektgegenstand vom Grobentwurf zum

Detailentwurf schrittweise speziﬁziert. Auf dem rechten Ast werden die unterschiedlichen

Realisierungs- und Veriﬁzierungsstufen von unten nach oben durchlaufen.

Einleitung

Validierung

Veriﬁzierung

Entwicklung

Programmierung

Integrationstest

Systemtest

Validierung, Freigabe

Komponenten-, Modul-

bzw. Unittest

Feinarchitektur,

Komponentendesign

Architektur, techni-

scher Systementwurf

Systemanforderungen

Systemspeziﬁkation

Stakeholder-

Anforderung

Abb. 1.14 V-Modell

1.4.5.2

Simultaneous Engineering

Simultaneous Engineering (auch Concurrent Engineering genannt) hat seinen Ursprung

in der Produktentwicklung. Die Forderung nach kürzeren Entwicklungszeiten führte zur

Entwicklung dieses Vorgehensmodells. Eine Parallelisierung der Abläufe beschleunigt die

Projektabwicklung. Die verschiedenen Bereiche, die an der Produktentwicklung beteiligt

sind, sollen möglichst frühzeitig einbezogen werden. Eine teilsimultane Erarbeitung wird

durch eine gezielt überlappende Anordnung der Phasen möglich, wie Abb. 1.15 zeigt.

Viele Projekte werden nach diesem Prinzip durchgeführt. Die Gleichzeitigkeit von un-

terschiedlichsten Aktivitäten erfordert vom Projektleiter eine laufende Überprüfung der

Ziel- und Planeinhaltung. Diese Aufgabe ist oftmals erschwert, wenn er noch fachlich im

Projekt mitarbeitet oder in anderen Projekten engagiert ist.

Wird Simultaneous Engineering für ein zeitlich enges, paralleles Projektvorgehen

durch den Auftraggeber vorgegeben oder bewilligt, sollte sich der Projektleiter frei von

weiteren Arbeiten voll der Steuerung des Projektes widmen können.

1.4.5.3

Prototyping

Der Begriff des Prototyping als Vorgehensprinzip tauchte in der Datenverarbeitung Mitte

der 1970er Jahre auf. Die Grundidee besteht darin, die vorerst abstrakten Lösungen schnel-

1.4

Vorgehensmodelle in Projekten

Korrekturschleife

Zeitgewinn

Marktanalyse

Konzeptentwicklung

Designphase

Marktanalyse, Konzeptent-

wicklung, Designphase

Aufbau der

Fertigung und

Produktionsanlauf

Aufbau der Fertigung

und Produktionsanlauf

Produktionsplanung

Betriebsmittel-

konstruktion

Produktionsplanung

Betriebsmittelkonstruktion

Produktentwicklung

Versuch

Produktentwicklung, Versuch

Sequenzieller Projektablauf

Projektstart

Markteinführung

Simultaneous Engineering

Korrekturschleife

Abb. 1.15 Simultaneous Engineering als überlappendes Phasenkonzept

ler zu konkretisieren, um damit eine efﬁzientere Kommunikation zwischen Entwicklern

und Anwendern zu erzielen. In diesem Sinne dient Prototyping als Entwurfshilfe, indem

es dazu beiträgt, die Bedürfnisse der Anwender schneller kennen zu lernen.

Konkret geht es darum, mit relativ geringem Aufwand einen „Prototyp“ zu entwerfen.

Dieser soll eine bessere Beurteilung des bisher verfolgten Konzepts erlauben. Auch dient

er häuﬁg dem Erproben unter betrieblichen Bedingungen.

Prototyping kann als Entwurfshilfe vor allem realisierungsnahe Phasen unterstützen.

Keine der einzelnen Phasen wird dadurch aber überﬂüssig. Vor allem kann die Konzept-

phase keineswegs ersetzt werden. Die beiden Phasen Konzept und Realisierung können

iterativ miteinander verknüpft werden. Allerdings besteht die Gefahr, dass der Ansatz zu

„quick and dirty“ Lösungen führt, die bei stetem Weiterausbau beibehalten werden. Bei

fehlendem Lösungskonzept führt dies zu Altlasten. Oder der Kunde hat den Eindruck:

„Die Lösung ist ja schon fertig. Wofür braucht ihr jetzt noch so viel Zeit?“

1.4.5.4

Versionenkonzept

Das Versionenkonzept weist Ähnlichkeiten mit dem Prototyping auf. Es ist für Entwick-

lungen beliebiger Art (Maschinen, Anlagen, Hard- und Software) einsetzbar.

Einleitung

Ziele, Alternativen und

Restriktionen bestimmen

nächsten Zyklus planen

Produktstufe entwickeln

und validieren

Alternative bewerten,

Risiko identiﬁzieren und

beseitigen

Test und

Validierung

Implementierung

Entwurf

Simulation

Protoypen entwickeln

Voruntersuchung

und Risikoanalyse

Abb. 1.16 Das Versionenkonzept (Spiralmodell)

Die Grundidee besteht darin, eine Lösung nicht in einem Wurf perfektionieren zu

wollen, sondern eine erste Version zu entwickeln und zu realisieren, die dem Benut-

zer zur Verfügung gestellt wird. Davon ausgehend ﬁnden dann von einer Version zur

anderen Verbesserungen statt („slowly growing systems“), die aufgrund der Betriebser-

fahrungen möglich werden. Dieses zyklische Vorgehen wird daher auch Spiralmodell

genannt (Abb. 1.16). Die Vor- und Nachteile des Versionenkonzeptes – auch Spiralmodell

genannt – sind in Tab. 1.6 dargelegt.

1.4.6

Wahl eines Vorgehensmodells – klassisch, agil oder hybrid?

Die Wahl des für die Situation am besten geeigneten Vorgehensmodelles hängt von ver-

schiedenen Faktoren ab:

Ausprägung des Projektes:

– Für ein Standardprojekt empﬁehlt sich die klassische Vorgehensweise.

– Für ein Akzeptanz-, Potential- oder Pionierprojekt ist eher eine agile oder hybride

Vorgehensweise zu empfehlen.

1.4

Vorgehensmodelle in Projekten

Tab. 1.6 Vor- und Nachteile des Versionenkonzepts

Vorteile

Nachteile

Oftmals „Notfall-Lösungen“

Lösung schnell verfügbar

Probleme bzw. Verbesserungen auf die nächste Version

verschieben zu können, verleitet zu unsorgfältiger Pla-

nung

Hohes Entwicklungstempo

Rasch sichtbare Fortschritte

Hohe Anforderungen an die Dokumentation und Projekt-

administration, da zu jedem Zeitpunkt nachvollziehbar

sein muss, wo welche Version gültig ist und wie die ein-

zelnen Komponenten einer Lösung realisiert wurden

bzw. voneinander abhängig sind

Möglichkeit, sich in ein Problem-

feld zu begeben, in dem noch wenig

Wissen vorhanden ist

Planung und Prognose der Projektkosten sind äußerst

schwierig

Bei beschränktem Budget können die

Ziele und Anforderungen (Perfekti-

onsgrad der Lösung) mit dem Budget

wachsen

Durch immer neue Anforderungen seitens der Benutzer

kann die Systemgrenze gesprengt werden; das Projekt

wird unkontrolliert erweitert bzw. kommt nie zum Ab-

schluss

Die Projektart gibt sehr oft ein Vorgehensmodell vor. Bauprojekte werden nach

entsprechender Branchen-Norm abgewickelt wie beispielsweise der des Schweizer

Ingenieur- und Architektenvereins SIA.

Auch geben Unternehmen, Kunden oder die Regulationsbehörden vor, welche Stan-

dards und Vorgaben einzuhalten sind.

Komplexität der Aufgabenstellung

– Mit dem Cyneﬁn-Framework (David J. Snowden, Abb. 1.17) und der Stacey-Matrix

Abb. 1.18 kann die Komplexität der Aufgabenstellung, resp. des Projektes bestimmt

werden.

– Für einfache oder komplizierte Aufgabenstellungen eignet sich eher die klassische,

für die Lösung komplexer und chaotischer Aufgabenstellungen hingegen eher eine

agile Vorgehensweise.

Stabilität der Anforderungen

– Für volatile Anforderungen eignet sich eher eine agile Vorgehensweise.

– Bei stabilen Anforderungen bringt die klassische Vorgehensweise mehr Sicherheit

und Planbarkeit in der Umsetzung.

– Weiter ist zu überlegen wie mit Änderungen im Projekt umgegangen werden soll.

Kompetenzen, Qualiﬁkationen und Erfahrungen der Mitglieder des Projektteams

sowie Afﬁnität des Managements zur Agilität sind weitere entscheidende Faktoren.

Geplante Teamgröße

– Für kleine Teams mit weniger als neun Personen sind agile Methoden sehr gut ge-

eignet.

– Große Teams können beispielsweise mittels LeSS (Large Scaled Scrum) sehr gut

agil arbeiten, wenn sie profunde Kenntnis und Erfahrung in der Anwendung von

agilen Methoden haben. Ansonsten empﬁehlt sich eher ein hybrider oder klassischer

Ansatz.

Einleitung

komplex

• alles ist im Fluss und nicht vorhersehbar,

• keine richtigen Antworten,

• etliche Unbekannte,

• erkennbare Orientierungsmuster,

• viele konkurrierende Ideen,

• kreative und innovative Ansätze sind nötig.

probiere – erkenne – reagiere

kompliziert

• das System ist vorhersehbar,

• Ursache und Wirkung sind

vorhanden, aber nicht für

jeden ersichtlich,

• Expertenrat ist nötig, aber

• mehr als eine richtige Antwort.

erkenne – analysiere – reagiere

chaotisch

• hohe Turbulenz,

• keine Ursache-Wirkungs-Beziehungen,

• große Unbekannte,

• viele Entscheidungen

unter hohem Zeitdruck.

handle – erkenne – reagiere

einfach

• wiederholbare Muster und

eindeutige Ereignisse,

• klare Ursachen und Wirkungen,

• klare Beziehungen,

• es gibt richtige Antworten.

erkenne – beurteile – reagiere

Abb. 1.17 Cyneﬁn-Framework nach David J. Snowden (vereinfachte Darstellung)

Räumliche Verteilung des Projektteams

– Für agiles Vorgehen ist es empfehlenswert, dass das Projektteam in einem gemein-

samen Raum oder wenigstens im gleichen Gebäude arbeitet.

– Die Anwendung agiler Methoden in verteilten Projektteams ist anspruchsvoll. Daher

ist bei räumlicher Verteilung ein hybrider oder klassischer Ansatz die erste Wahl.

Die Wahl eines geeigneten Vorgehensmodelles ist eine anspruchsvolle Aufgabe. Sie

soll am Anfang durch den Auftraggeber zusammen mit dem Projektleiter erfolgen. Ein

Wechsel des Vorgehensmodells im Projektablauf ist möglich, sollte aber gut überlegt und

bewusst vollzogen werden. Von Ad-hoc-Änderungen im Vorgehensmodell ist abzuraten.

Noch zu oft lässt sich beobachten, dass Unternehmen agile Methoden und Abläufe in Pro-

jekten oder in Teilen davon einsetzen, die entsprechenden Teams aber nicht entsprechend

befähigen, agil zu handeln. Tab. 1.7 gibt eine Hilfestellung für die Auswahl des Vorge-

hensmodelles.

1.4

Vorgehensmodelle in Projekten

WIE: Technologie

WAS: Anforderungen

klar

sicher

unklar

unsicher

politisch

chaotisch

kompliziert

visionär

komplex

einfach

Abb. 1.18 Stacey-Matrix

Tab. 1.7 Kriterien für Auswahl eines geeigneten Vorgehensmodelles

Klassisch

Agil

Hybrid

Ausprägung des Pro-

jektes

Standardprojekt

Potenzialprojekt oder

Pionierprojekt

Pionierprojekt, Ak-

zeptanzprojekt oder

Potentialprojekt

Komplexität der Auf-

gabenstellung

Einfach oder kompli-

ziert

Komplex oder chao-

tisch

Kompliziert oder kom-

plex

Stabilität der Anforde-

rungen

Stabil

Volatil

Qualiﬁkationen Team-

mitglieder

Unerfahren in agilen

Vorgehensweisen

Erfahren in agilen

Vorgehensweisen

Erfahren in agilen

Vorgehensweisen

Teamgröße

Kleine und grosse

Teams

Idealerweise weniger

als neun Personen.

Mehrere vernetzte

Teams möglich

Große Teams

Räumliche Verteilung

Lokal oder verteilt

über mehrere Stand-

orte

Lokal in einem Raum

oder am selben Stand-

ort

Verteilt über mehrere

Standorte

Einleitung

1.5

Projekte basieren auf Teamarbeit

Projektarbeit ist immer Teamarbeit. Eine Einzelperson kann die Komplexität eines Projek-

tes nicht alleine bewältigen, sondern nur im Verbund mit anderen. Damit ist die Zusam-

menarbeit im Team ein wesentlicher Erfolgsfaktor im Projektmanagement. Das Modell

der drei Ebenen der Zusammenarbeit in Abb. 1.19 fasst die Anforderungen an die Team-

arbeit zusammen.

1.5.1

Inhalt: Arbeit im System

Sinn und Existenzgrund eines Projektes ist immer der Scope, sei es ein Produkt, eine

Dienstleistung, eine Applikation, ein Prozess oder die Weiterentwicklung der Organisati-

onskultur. In irgendeiner Art und Weise muss für die Organisation oder den Kunden ein

Mehrwert geschaffen werden.

Damit mehrere Personen auf einen gemeinsamen Scope hinarbeiten können, müs-

sen sie diesen kennen und wissen, worum es geht. Ziele und Restriktionen leiten sie,

Sachentscheide richtig zu fällen und entsprechende Dokumente zu erstellen, z. B. Kon-

Beziehung

Interdisziplinäre Zusammenarbeit

Gestalten der Beziehungen, Vertrauen, persönliche

Kommunikation, Projektkultur, Umgang mit Konﬂikten

Inhalt

Wissen, worum es geht

Produktive Arbeit, Anforderungen und Scope,

Kosten, Zeit, Entscheidungen, Konzepte

Organisation

Gestalten der Zusammenarbeit

Projektorganisation, Anbindung an die Stammorganisa-

tion, Vorgehensweise (Strukturen, Prozesse, Methoden)

Arbeit im

System

Arbeit am

System

Abb. 1.19 Die drei Ebenen der Zusammenarbeit

1.5

Projekte basieren auf Teamarbeit

zepte, Lasten- und Pﬂichtenhefte, Projektauftrag oder Produktvision, Product Backlog

und Sprint Backlog. Auch die produktive Arbeit ist auf dieser Ebene angesiedelt.

1.5.2

Organisation und Beziehung: Arbeit am System

Damit mehrere Personen einen gemeinsamen Scope erreichen können, müssen für ihre

Zusammenarbeit Rahmenbedingungen erfüllt sein.

Organisation

Die Stammorganisation stellt dem Projekt die ﬁnanziellen, technischen und personellen

Ressourcen sicher. Das Projekt ist somit immer von der Stammorganisation abhängig.

Bewusst oder unbewusst wirken aus der organisatorischen Ebene u. a. folgende Aspekte

auf das Projekt:

Anbindung des Projektes an die führende Stammorganisation (Abschn. 2.3.9.8)

Position, Rollen und Rollenübernahme in der Projektorganisation (Abschn. 4.1.9)

Methodische Guidelines, Leitfäden oder Handbücher (Abschn. 2.3.13)

Kompetenzregelungen (Abschn. 2.3.9) und Kommunikationsprozesse (Abschn. 3.9.4)

Beziehung

Die interdisziplinäre Zusammenarbeit ist integraler Bestandteil von Projektmanagement.

Sie wird der Ebene der Beziehung zugeordnet. Der Mensch als soziales Wesen ist darauf

angewiesen, tragfähige Beziehungen leben zu können. Dadurch kann er auch wesentli-

che Grundbedürfnisse befriedigen, wie die nach Geborgenheit, sozialer Anerkennung und

nach Selbstentfaltung (Abschn. 3.3.3). Dazu ist es so wichtig, dass der Mensch sich als

Teil eines größeren Ganzen wahrnehmen kann. Wie in Abschn. 1.6.2 ausgeführt, ist der

Mensch ein nicht-triviales System: Sein Verhalten ist weder von außen steuer- noch vor-

hersehbar. Gesteuert werden kann jedoch die Gestaltung der Beziehungen zwischen den

Menschen in einer Gruppe. Erster Schritt zu dieser Beziehungsgestaltung ist im Projekt-

management die Stakeholder-Analyse mit dem Kommunikationskonzept. Zudem haben

weitere Aspekte einen Einﬂuss:

Wie gut sind die Vertrauensbasis (Abschn. 3.3.7) und der Zusammenhalt (Abschn.

4.2.3) entwickelt?

Wie funktionieren das formelle und informelle Netzwerk (Abschn. 4.1.3.3)?

Wie wird kommuniziert (Abschn. 3.9) und mit Feedback umgegangen (Abschn. 3.9.7)?

Wie geht ein Team mit Problemen oder auch mit dem Scheitern um (Abschn. 3.8.5)?

Wie werden Verhandlungen geführt (Abschn. 4.3) und Konﬂikte bewältigt (Abschn.

4.4)?

Wie wird die Projektkultur gestaltet (Abschn. 4.1.14.2)?

Einleitung

1.5.3

Wechselwirkungen

Natürlich bestehen zwischen den drei Ebenen der Zusammenarbeit Wechselwirkungen.

Unklare Ziele oder eine widersprüchliche Projektorganisation werden über kurz oder lang

auf der Beziehungsebene sichtbar und können sich in Form von persönlichen oder seeli-

schen Konﬂikten manifestieren (Abschn. 4.4.2).

Zudem sind auch die Bedürfnisse der einzelnen Teammitglieder unterschiedlich: Die

einen wollen sofort an den inhaltlichen Themen arbeiten, da dies die Ebene ist, auf der sie

sich sicher fühlen. Die anderen können gar nicht inhaltlich arbeiten, bevor sie gut entwi-

ckelte Beziehungen und eine solide Vertrauensbasis für einen offenen Austausch haben.

Die Bedürfnisse der Individuen sind da – abhängig von der Ausprägung der Grundbedürf-

nisse Abschn. 3.3.3 unterschiedlich. Erfasst werden können sie durch Persönlichkeitsty-

pologien wie Belbin oder MBTI (Abschn. 3.10.2).

Eine wichtige Aufgabe des Projektleiters, Product Owners und des Scrum Masters ist

es, den Zusammenhalt im Team zu fördern und zu entwickeln. Wenn dies gelingt, zieht

das Team am gleichen Strick in die gleiche Richtung (Abb. 1.20).

Projektziel

Zusammenhalt im Team

entwickeln und fördern …

… und mit Zugkraft und Entschlos-

senheit zielorientiert arbeiten

Abb. 1.20 Teambildung und Zugkraft

1.6

Projekte sind soziale Systeme

1.6

Projekte sind soziale Systeme

1.6.1

Taylorismus in unseren Köpfen

Wir Menschen organisieren unser Leben gerne vorhersehbar und berechenbar. Dies ver-

mittelt uns (vermeintliche) Sicherheit. Diese Haltung ist eine wichtige Grundlage für die

in Abschn. 1.1 vorgestellte Taylorwanne. Frederick Taylor entwickelte seine Theorie um

das Jahr 1910. Damals sanken die Transportkosten, und es wurden immer mehr Maschinen

erfunden. Damit eröffnete sich den Unternehmen erstmals der globale Markt. Innovation

war damals nicht entscheidend, weil wenig Konkurrenz bestand. Und wo ein Mitbewerber

auftrat, konnte der auf einen anderen Markt ausweichen.

Oben wird gedacht, Unten gemacht

Das Mantra des Taylorismus war, dass der Mensch wie eine Maschine zu funktionieren

habe (Oestereich und Schröder 2017, S. 7). Disziplin stand an erster Stelle. Die bestehen-

den Regeln und Prozesse waren einzuhalten. Jeder Arbeitsschritt war genau vorgegeben.

Mitdenken und Kreativität der Arbeiter waren nicht erwünscht. Es wurde klar unterschie-

den zwischen dem Denken und dem Handeln. Die Vorgesetzten legten die Methoden fest

und fällten die Entscheide, die Arbeiter waren für die Umsetzung verantwortlich.

Heute besteht ein hoher Innovationsdruck in globalen Märkten. Das führt dazu, dass

die Komplexität in der Projektarbeit um ein Vielfaches zunimmt. Die Trennung zwischen

Denken und Handeln ist nicht mehr praktikabel oder sehr inneffektiv: Wenn die Entschei-

de nicht durch die Personen gefällt werden können, die die speziﬁsche Fachkompetenz,

die Nähe zur Problemstellung oder zum entsprechenden Markt haben, zieht dies in hierar-

chisch geprägten Organisationen Kommunikations- und Entscheidungsprozesse von sehr

geringer Wertschöpfung nach sich.

Das agile Projektmanagement führt das Denken und Handeln wieder zusammen, indem

es den Product Owner mit weitreichenden Entscheidungskompetenzen ausstattet und dem

Team die Autonomie einräumt, während der Sprints selbst zu entscheiden.

Nur mit der Anpassung der Methoden gelingt der Wandel zur Netzwerkökonomie aber

nicht: Es braucht die entsprechende Haltung, ein adäquates Menschen- und Weltbild.

1.6.2

Menschen und Teams sind nicht-triviale Systeme

Wer Kinder hat, erfährt immer wieder: Was man ihnen sagt (Input) und was sie schließlich

tun (Output), kann meilenweit voneinander entfernt sein. Auch in der beruﬂichen Zusam-

menarbeit erfahren wir immer wieder, dass eine vermeintlich klare Instruktion an einen

Kollegen eine völlig unerwartete Reaktion bewirkt. Dieses Phänomen erklärt Heinz von

Foerster durch den Begriff der trivialen- und nicht-trivialen Systeme (Abb. 1.21).

Einleitung

Output

Input

Output

Input

Abb. 1.21 Triviale und nicht-triviale Systeme. (Seliger 2014, S. 67 f.)

Triviale Systeme: Fremdsteuerung

Ein triviales System basiert auf der Logik, dass aufgrund eines klar speziﬁzierten Inputs

eine speziﬁsche Funktion ausgelöst wird, die dann zu einem klar deﬁnierten Output führt.

Im Taylorismus hatte der Mensch wie eine Maschine zu funktionieren; das Menschenbild

wurde also geprägt durch die Logik der trivialen Maschine.

Diese Deﬁnition trifft in der unbelebten Natur (Mineralien, anorganische Substanzen)

sowie bei mechanischen, elektronischen und IT-Systemen zu – oder sollte es zumindest.

Autos, Schiffe oder Flugzeuge sind so gebaut, dass sie über die Handlungen aus dem

Cockpit gesteuert werden. Unsere Computer mit all den Programmen und Applikationen

sind daraufhin ausgerichtet, aufgrund speziﬁscher Eingaben der Benutzer über das Pro-

gramm speziﬁsche Leistungen und Outputs zu generieren.

Nicht-triviale Systeme: Selbststeuerung

Alles was lebt, ist nicht-trivial, seien es Organismen wie Pﬂanzen oder Tiere, einzelne

Menschen, Projektteams und andere Organisationen. Lebendige Systeme sind selbstor-

ganisiert und von außen nicht steuerbar. Nie ist mit absoluter Gewissheit vorherseh- und

planbar, was die Reaktion (Output) auf eine speziﬁsche Anweisung (Input) sein wird.

1.6

Projekte sind soziale Systeme

Eine in bester Absicht an einen Kollegen gerichtete Bemerkung kann dieser völlig

falsch auffassen. Seine aus einem Affekt hervorgegangene Reaktion macht dies deutlich.

Oder: Trotz einem unterzeichneten Projektauftrag und klar geregelten Prioritäten im Pro-

jektportfolio werden dem Projektleiter die Ressourcen nicht zur Verfügung gestellt. In

unserem privaten und beruﬂichen Leben sind wir immer wieder mit Verhaltensweisen von

anderen Menschen konfrontiert, welche nicht der Erwartung oder Abmachung entspre-

chen.

Diese Unvorhersehbarkeit ist darin begründet, dass die Funktion durch den Zustand des

Systems immer wieder neu beeinﬂusst wird. Dieser Zustand kann je nach Situation durch

ganz unterschiedliche Faktoren beeinﬂusst werden: Erfahrungen, Persönlichkeitsmerkma-

le, Interessen, Gefühle, Stimmung, Menschen- oder Weltbilder (Seliger 2014, S. 67).

Einzelne Menschen oder Teams haben ganz viele unterschiedliche Möglichkeiten, auf

Impulse von außen zu reagieren. Sie sind grundsätzlich selbstgesteuert und unberechen-

bar. Der Taylorismus baute auf einem gegenteiligen Menschenbild auf. Wie so oft dürfte

die Wahrheit in der Mitte liegen: Der Mensch kann nicht jederzeit einfach all seine Stim-

mungen und Impulse ausleben. Gemeinschaften wie Familien oder Projektteams sind

darauf angewiesen, dass das Verhalten eines Menschen innerhalb von gewissen Normen

und Konventionen abläuft. Von dem her muss sich der Mensch zu gewissen Teilen „tri-

vialisieren“ lassen, um für andere berechenbar zu werden. Nur so kann die Komplexität

des Zusammenlebens reduziert werden. In der Gesellschaft heißt das, dass wir die Ge-

setze einhalten. Auch Projektteams können nur funktionieren, wenn eine Rollenklärung

stattﬁndet (Abschn. 4.1.9) und gemeinsame Regeln der Zusammenarbeit deﬁniert werden

(Abschn. 4.2.3). Mit und trotz aller Abmachungen und Regeln ist die Natur des Menschen

„nicht-trivial“, weshalb es immer wieder zu nicht vorhersehbaren Reaktionen kommen

kann. Dies wiederum führt oft zu Konﬂikten (Abschn. 4.4) und macht das Gestalten von

Veränderungsprozessen so anspruchsvoll (Abschn. 4.5).

1.6.3

Systemischer Ansatz im Projektmanagement

Mit „systemischem Projektmanagement“ ist ein ganzheitliches Projektmanagement ge-

meint, bei dem die menschlichen Aspekte eine wesentliche Rolle spielen. Der systemische

Ansatz geht davon aus, dass Projekte soziale Systeme sind, welche eigendynamisch und

selbstreferentiell wirken und mit der Umwelt vernetzt sind. Ihre kleinste Einheit ist nicht

der Mensch, sondern die persönliche Kommunikation (Abschn. 3.9). Somit ist das Augen-

merk auf die kommunikativen Beziehungen zwischen Menschen und Gruppen zu richten:

Rahmenbedingungen, Spielregeln, Dynamiken und Spannungen. Diese Betrachtungswei-

se verhilft u. a. zu folgenden Erkenntnissen:

Betriebliche Rahmenbedingungen

Das System „Projekt“ steht in Beziehung zum System „Stammorganisation“. Durch die

unterschiedlichen Kulturen entsteht eine Spannung zwischen den beiden Systemen. Die

Einleitung

Unterschiede zwischen der Welt „Stammorganisation“ und der Welt „Projekt“ sind be-

einﬂussbar, beispielsweise durch den Grad an Gestaltungs- und Entscheidungsfreiheit im

Projekt und die Ressourcenzuteilung. Die Nominierung und Ausgestaltung der Projekt-

rollen oder die Regeln der Kommunikation sind konkrete Beispiele dazu. Solche Maß-

nahmen erhöhen die gegenseitige Aufmerksamkeit und sensibilisieren dafür, dass die

Aufmerksamkeit gesteuert werden kann (Kreativität Abschn. 1.7.2). Die damit gewon-

nene organisationale Dynamik gibt dem Projekt Energie. Oft wird aber den betrieblichen

Rahmenbedingungen – und damit der Arbeit am System – wenig Aufmerksamkeit ge-

schenkt. Daher unterstützen sie Projekte oft kaum (Dierig 2015).

Selbststeuerung

Eine rigide Fremdsteuerung widerspricht den Grundsätzen nicht-trivialer Systeme und des

systemischen Weltbildes. Dies hat man im agilen Projektmanagement wie beispielsweise

Scrum erkannt: Die Selbststeuerung des Teams ist hier integraler Bestandteil. Der Scrum

Master ist explizit für die Rahmenbedingungen verantwortlich. Er arbeitet als „Kontext-

manager“ am System. Das Team organisiert sich selber und arbeitet damit sowohl im, als

auch am System (Kollegiale Führung Abschn. 4.1.2). Das mag irritieren, bedeutet es doch

einen Paradigmenwechsel gegenüber den klaren Hierarchien, die in vielen Organisationen

heute noch anzutreffen sind.

Stakeholder Management

Beeinﬂusst vom Systemdenken ist auch das Stakeholder Management (Abschn. 2.3.5).

Dadurch werden u. a. die Beziehungen zu den beteiligten Menschen und Gruppen im

und ums System Projekt analysiert sowie Unterstützungen, kritische Haltungen oder un-

terschiedliche Interessen in Bezug auf das Projekt festgestellt. Das ist die Basis für die

Projektorganisation und die Projektkommunikation.

Netzwerke

Noch wenig wird mit Vernetzung gearbeitet. So können z. B. Teilprojektteams, die gegen-

seitig vernetzt – statt durch einen Gesamtprojektleiter koordiniert – werden, in komplexen

Situationen eine weit höhere Koordinationsleistung erbringen.

1.6.4

Mechanistisches und systemisches Weltbild

Ob Gift oder Medizin entscheidet das Maß (Paracelsus).

Taylor basierte seine Lehre auf einem mechanistischen Weltbild. Dieses ist geprägt von

der Überzeugung, dass der Mensch und die Organisation über Logik und lineare Kausal-

ketten erklärbar sind. Hier dominieren harte Fakten und die Überzeugung, dass es eine

gemeinsame Objektivität und damit auch eine Wahrheit gibt. Die in Abschn. 1.6.3 aus-

1.6

Projekte sind soziale Systeme

Tab. 1.8 Basierend auf Königswieser und Hillebrand (2004, S. 28)

Mechanistisches Weltbild

Systemisches Weltbild

Objektivität, eine Wahrheit, unveränderliche

Gesetze

Wirklichkeitskonstruktion, viele Wahrheiten,

Hypothesen

Richtig – falsch, schuldig – unschuldig

Kontextabhängigkeit, Nützlichkeit, Anschluss-

fähigkeit

Fremdsteuerung

Selbststeuerung, Selbstorganisation

Lineare Kausalketten

Vielfältige Wechselwirkungen

Formale Logik, Widerspruchsfreiheit

Integration von Widersprüchen

Harte Fakten, rationale Beziehungen

Integration von harten und weichen Faktoren

(Emotionen, Intuition)

geführten Aspekte des systemischen Projektmanagements basieren auf dem systemischen

Weltbild.

In Tab. 1.8 sind wesentliche Unterschiede zwischen diesen beiden Weltbildern gegen-

übergestellt.

Jede Organisation, die Projekte abwickelt, ist ein lebendiges und damit ein nicht-

triviales System. Damit wird der systemische Ansatz zu einem integralen Bestandteil

jeder Projektorganisation, egal ob diese nach dem agilen oder klassischen Ansatz arbeitet.

Es soll hier weder darum gehen, das mechanistische Weltbild schlecht zu machen noch

die Taylorwanne auszukippen. Für gewisse Projekte eignet sich der klassische Ansatz bes-

ser, für andere der agile. Natürlich geht es in der Projektarbeit auch um harte Fakten. Das

Budget muss besprochen und das Controlling abgewickelt werden. Komplexitäten müs-

sen abstrahiert und lineare Kausalketten gebildet werden. Aber in der Zusammenarbeit

von Menschen geht es immer auch um die Aspekte des systemischen Weltbildes. Wie das

Sprichwort von Paracelsus offenbart, ist es das Maß, welches das Gift von der Medizin un-

terscheidet: Wer nur im mechanistischen Denken zuhause ist, wird einmal die Erfahrung

machen, dass er konfrontiert wird mit Phänomenen wie Widerstand und Konﬂikt. Auch

könnte er nicht in der Lage sein, kreative Lösungen zu ﬁnden. Bei denen, die sich nur am

systemischen Denken orientieren, ist die Gefahr groß, dass sie Ursache-Wirkungsprinzi-

pen nicht erfassen oder kreative Lösungen entwickeln, die kein Kunde bezahlen will.

Es geht nicht um das „Entweder-Oder“. Der Umgang mit Polaritäten und damit die In-

tegration der Gegensätze mit dem „Sowohl-Als-Auch“ soll maßvoll zwischen den Polen

ausbalancieren: Je nach Fragestellung oder Situation sollten wir in der Lage sein abzu-

schätzen, welche Haltung oder welches Denken zielführend ist.

Die Erfahrungen zeigen jedenfalls, dass der systemische Ansatz eine äußerst wirkungs-

volle Gestaltungsmöglichkeit für das klassische wie auch das agile Projektmanagement

bietet. Wichtig ist zu wissen, dass die Systembetrachtung nicht die psychologischen bzw.

die gruppendynamischen Grundsätze ablöst. Beide ergänzen sich.

Im klassischen Projektmanagement steht die Fremdsteuerung mehr im Vordergrund:

Auftraggeber und Projektleiter sind die beiden zentralen Rollen, die mit den wesentlichen

Einleitung

Entscheidungskompetenzen ausgestattet sind. Natürlich müssen auch die Erwartungen

und Zuständigkeiten der anderen Stakeholder geklärt werden, was z. B. mit einer RACI-

Matrix dargestellt werden kann (Abschn. 2.3.9.9). Auch die Ziele werden zu Beginn des

Projektes so gut wie möglich speziﬁziert.

Der Projektleiter ist oft damit herausgefordert, dass er sowohl für die Arbeit am System

wie auch für die Arbeit im System zuständig ist. In kleineren und mittleren Projekten

ist der Projektleiter oft auch eine wesentliche technische Ressource. Der hohe Zeitdruck

verleitet diesen dann dazu, seine knappen Ressourcen auf die produktive Arbeit im System

zu fokussieren. Die Arbeit am System steht dann im Hintergrund. So wird ein Projekt

Kick-off in nur einer Stunde durchgeführt. Das reicht knapp dafür, ein Verständnis von

der Aufgabe zu erhalten. Aber es ist weit davon entfernt, ein soziales Teamgefüge und

einen Organisationsrahmen zu gestalten, in dem sich die Mitglieder als Teil eines größeren

Ganzen verstehen können. Damit fehlen auch die Klärungs- und Erörterungsgrundlagen

in einer frühen Phase der Zusammenarbeit, was sich dann während der Projektabwicklung

in speziﬁschen Symptomen wie Konﬂikten und Widerständen manifestiert.

Im agilen Projektmanagement steht die Selbststeuerung mehr im Vordergrund. Das

Team muss die Führungsarbeit unter sich aufteilen und kann damit Denken und Handeln

zusammenführen. Auch die Vernetzung zu internen und externen Stakeholdern wird nicht

über die Hierarchie geregelt, was ebenfalls anspruchsvoll ist.

Den Projektleiter gibt es in diesem Ansatz nicht. Durch den Scrum Master wird in

diesem Ansatz explizit eine Rolle geschaffen, welche keine inhaltlich produktive Arbeit

leisten soll oder kann, sondern sich vollumfänglich auf die Arbeit am System konzentriert.

Der Scrum Master ist einzig und alleine dafür da, die optimale Zusammenarbeit zwischen

den beiden „produktiven“ Rollen Product Owner und Team sicherzustellen. Zudem ist

seine Aufgabe, Hindernisse, mit welchen das Team konfrontiert wird, aus dem Weg zu

räumen und zu gewährleisten, dass die jeweiligen Anforderungen und Herausforderungen

mit den optimalen methodischen Ansätzen bearbeitet werden.

1.7

Vielseitigkeit und Kreativität

Der Existenzgrund von jedem Projekt ist es, etwas Neues zu schaffen. Sei es eine neue

Kundenanfrage oder eine interne Problemstellung: Die vorhandenen Produkte und Lö-

sungsstrategien genügen den neuen Anforderungen nicht (mehr).

Die Anforderung an die Kreativität ist in einem Standardprojekt (Abschn. 1.2.1) eher

gering, in einem Potential- oder Pionierprojekt jedoch sehr hoch. Darauf wird im zweiten

Teil dieses Abschnittes eingegangen. Immer wesentlich für Projektverantwortliche ist ihre

Vielseitigkeit.

1.7

Vielseitigkeit und Kreativität

1.7.1

Vielseitigkeit

In Projekten müssen Ziele von mittlerer bis hoher Komplexität in einem beschränkten

Zeitraum mit interdisziplinären Teams erreicht werden. Auch wenn eine Organisation

schon viele ähnliche Projekte abgewickelt hat, führt ein einfaches „copy-paste“ eines

abgeschlossenen Projektauftrages oder -plans nicht zum Ziel. Projekte sind als soziale,

lebende Systeme immer in einem Entwicklungs- und Lernprozess. Die Professionalität

von Projektverantwortlichen in beiden Ansätzen liegt darin, dass es ihnen immer wieder

neu gelingt, aufgrund der aktuellen Situation die wirkungsvollste Strategie zu wählen. Das

äußert sich in den Vorgehensprinzipien (Abschn. 1.3.3) oder in der Wahl der Vorgehens-

modelle (Abschn. 1.4.6) oder in der Gestaltung der Zusammenarbeit (Abschn. 1.5). Jedes

neue Projekt eröffnet wieder neue Handlungsspielräume, die die Projektverantwortlichen

erkennen und ausnützen sollen. Viel kann schon erreicht werden, wenn die bestehenden

Ressourcen und Kompetenzen optimal in die Gestaltung der neuen Projekte einﬂießen.

1.7.2

Kreativität als Überschuss von Aufmerksamkeit

Die Krone der Vielseitigkeit trägt die Kreativität. Hier geht es darum, Innovation zu

schaffen, Ideen und Lösungsansätze zu entwickeln, die in ihrer Art neu sind. Speziﬁ-

sche Kreativitätstechniken werden in Abschn. 2.8 ausgeführt. Hier sind zu diesem Thema

grundlegende Gedanken in Zusammenhang mit dem Menschen und der Organisation dar-

gestellt.

Der Psychologe Mihaly Csikszentmihalyi hat die Kreativität wissenschaftlich unter-

sucht. Er betrachtet Kreativität als die zentrale Sinnquelle des Menschen. Denn alle

kulturellen Errungenschaften des Menschen, sei es die Sprache, Technik, Wissenschaft,

Kunst oder Wirtschaft, sind Resultate der menschlichen Kreativität (Csikszentmihalyi

2015, S. 9).

Wer innovativ sein will, wer wirklich nachhaltig etwas Neues schaffen will, braucht

viel Energie. Altbewährtes muss losgelassen und die Grenzen des Wissens müssen über-

schritten werden. Kreativität erfordert immer wieder, neu zu lernen. Dies ist nicht nur ein

lustvoller Prozess; oft ist das auch mit Mühe, Anstrengung und Rückschlägen verbunden.

Der Mensch ist ein begrenztes Wesen. Wir können zu einem Zeitpunkt nur eine be-

schränkte Menge an Informationen aufnehmen und verarbeiten. Wenn wir etwas lernen

wollen, müssen wir diesem Thema unsere Aufmerksamkeit schenken. Das Problem ist,

dass auch unsere Aufmerksamkeit beschränkt ist. Zuallererst braucht der Mensch seine

Aufmerksamkeit, um sein Überleben zu sichern. Solange unser Grundbedürfnis nach kör-

perlicher Integrität nicht befriedigt ist (Abschn. 3.3.3), können wir uns um nichts Anderes

kümmern. Dazu kommen viele weitere Erwartungen aus Familie, Freundeskreis und Ge-

sellschaft, die unsere Aufmerksamkeit erfordern. Im Berufsalltag dasselbe Lied: vieles

erfordert Aufmerksamkeit. Je stärker wir absorbiert werden durch betriebliche Notwen-

Einleitung

digkeiten aus der Linien- oder Projektarbeit, desto weniger Aufmerksamkeit bleibt übrig

für das nachhaltige Schaffen von Neuem.

Für Csikszentmihalyi ist Kreativität immer nur dann möglich, wenn ein Überschuss

an Aufmerksamkeit vorhanden ist (2015, S. 20). Solange der Mensch völlig absorbiert

ist mit sich und anderem, kann er nicht die Energie für Innovation aufbringen. Das be-

weist auch der Blick zurück in die Geschichte: Wesentliche Kreativitätsschübe der Men-

schen fanden z. B. statt in Athen 500 v. Chr., in Florenz im 15. Jahrhundert oder in Paris

im 19. Jahrhundert. Es handelte sich dabei immer um Orte und Zeiten mit relativ ho-

hem materiellem Wohlstand. Dies erlaubte den Menschen, ihre Aufmerksamkeit über das

Überlebensnotwendige heraus auf andere Lebensinhalte zu lenken. So wurden enorme

Entwicklungsschritte in Philosophie, Kunst, Architektur und Wissenschaft ermöglicht.

1.7.3

Wechselspiel zwischen Mensch, Feld und Domäne

Kreativität ist jede Handlung, Idee oder Sache, die eine bestehende Domäne verändert oder

eine bestehende Domäne in eine neue verwandelt (Csikszentmihalyi 2015, S. 48).

Eine weitere Differenzierung scheint angebracht in der Quelle der Kreativität. Vielfach

wird der einzelne Mensch mit seinen guten Ideen als wichtigster Faktor für Kreativität

bezeichnet. Natürlich sind diese wichtig. Damit eine Idee jedoch sichtbar wird, ist ein

anderer Aspekt wesentlich: Sie muss für andere Menschen verständlich sein und von Ex-

perten im speziﬁschen Fachbereich anerkannt werden. Ansonsten kann keine nachhaltige

Innovation stattﬁnden.

Damit ist Kreativität immer auch das Resultat von Wechselbeziehungen zwischen

Menschen oder Gruppen, die eine neue Idee haben, Experten (Feld), die diese Idee

bewerten können und einem Fachbereich (Domäne), welcher durch diese Idee verändert

wird (Csikszentmihalyi 2015, S. 47 ff.):

Mensch

Was einen Wert hat, hat einen Preis.

Der Erﬁndergeist des Menschen ist die Quelle unserer Kulturgüter und Technologie. Ak-

tuell ist der Mensch daran, seine Vorreiterrolle in der Kreativität an die künstliche In-

telligenz zu verlieren. Enorme Mittel ﬂießen in die Weiterentwicklung der künstlichen

Intelligenz. Maschinen und Roboter werden lernfähig und autonom und schlagen den

Menschen im Schachspielen und anderem. Für Dennis Lück (Lück, NZZaS, 11.03.2018)

ist es ein großer Widerspruch, dass einerseits alles dafür gemacht wird, die künstliche In-

telligenz zu fördern, während andererseits die Grundlagen der menschlichen Kreativität

zu wenig gefördert werden.

Neben der Erbanlage hat die Umwelt einen wesentlichen Einﬂuss auf die Kreativität

des Menschen (Abschn. 3.3). Damit rückt das Schulsystem in den Fokus. Oft steht in

1.7

Vielseitigkeit und Kreativität

den Schulen noch die Erarbeitung des Wissens im Vordergrund. Was es aber braucht, um

kreativ zu sein, sind Kompetenzen oder Skills: Es geht darum, in komplexen Situationen

neue Lösungsansätze zu entwickeln (Abschn. 2.3.15), die bestehenden Regeln und Me-

thoden in Frage zu stellen, aus Fehlern und dem Scheitern zu lernen (Abschn. 3.8.5,) und

Perspektiven zu wechseln (Abschn. 3.9.8.3). Lück empﬁehlt für die Schulen mehr Pro-

jektarbeiten, durch welche die Schüler zusammen an Themen arbeiten können, welche sie

wirklich interessieren. So entwickeln sie mehr ihre Kompetenzen, als dass sie Wissen mit

Verfalldatum anhäufen. Dank dem, dass der Mensch sein Leben lang lernfähig ist, gelten

diese Empfehlungen auch für alle Organisationen, die Projekte abwickeln.

Kreativität ist nicht gratis zu haben: Für wen sie einen Wert hat, der muss auch bereit

sein, einen Preis dafür zu bezahlen.

Beispiel

In Bezug auf Scrum waren es Jeff Sutherland und Ken Schwaber, die sich Mitte der

1990er Jahre fragten, wie die Software-Entwicklung effektiver gestaltet werden kann.

Schwaber und Sutherland entwickelten neue Ideen zur Abwicklung von Projekten, weil

ihnen die gängigen Projektmanagement-Ansätze zu wenig zielführend schienen.

Um kreativ zu sein, muss ein Mensch außerhalb der gängigen Normen und Gewohnhei-

ten denken können. Damit stellt er das bestehende System in Frage und konfrontiert dieses

mit seinen Schwächen. Maßnahmen zur Förderung von Kreativität sind in Abschn. 1.7.4

aufgeführt.

Feld

Das Feld besteht aus Experten und Opinion Leaders, welche den Gehalt einer neuen

Idee abschätzen können und von welchen auch abhängt, ob eine Idee weiter entwickelt

werden soll oder kann. Zum Feld gehören alle Personen und Organisationen, die den Zu-

gang zu einem Fachbereich (Domäne) überwachen. Diese entscheiden, welche Idee oder

welches neue Produkt in eine Domäne aufgenommen werden soll. Im Projektmanage-

ment besteht das Feld im Wesentlichen aus den Standards und Zertiﬁzierungsmodellen

(Abschn. 1.8). Was hier aufgenommen wird, wird Teil der Domäne. Zum Feld der Domäne

Projektmanagement gehören auch die Fachgremien und Communities, Verlage, etablierte

Autoren oder Beratungs- und Bildungsinstitutionen.

Wären die Ideen von Schwaber und Sutherland nicht von Repräsentanten des Feldes

aufgenommen worden, es wäre nun wohl kaum ein etabliertes Verfahren geworden, das

mittlerweile in vielen Bereichen angewendet wird.

In einer Firma wird das Feld oft gebildet durch die Mitglieder des Managements, den

Leiter des PMO oder die Auftraggeber in den Projekten. Sie werden mit den Ideen und

kreativen Vorschlägen ihrer Mitarbeiter konfrontiert. Was sie gutheißen, kann nachhaltige

Veränderung bewirken. Was sie jedoch ablehnen oder verhindern, ist in den meisten Fällen

verloren.

Einleitung

Domäne

Im Beispiel von Sutherland und Schwaber wurden ihre Ideen des agilen Projektmanage-

ments in das „Kulturgut“ Projektmanagement übernommen. Dieses bezeichnet Csikszent-

mihalyi als Domäne. Hier wird das Wissen gesammelt und bewirtschaftet, was für einen

speziﬁschen Fachbereich anerkannt ist und Gültigkeit hat.

Jede Firma hat im Bereich ihrer speziﬁschen Geschäftstätigkeit auch eine oder mehrere

Domänen, welche es ihnen erlauben, eine Wertschöpfung zu entwickeln. Diese Domäne

kann in speziﬁschen Technologien oder Dienstleistungen liegen und ist immer auch ver-

bunden mit einer speziﬁschen Prozesskompetenz, wie den Kunden die Leistungen zur

Verfügung gestellt werden.

Jede Projektorganisation hat in irgendeiner Art auch Erfahrungen gesammelt, was in

ihrem speziﬁschen Geschäftsfeld die beste Art und Weise ist, Projekte abzuwickeln. Meis-

tens ﬁndet das Niederschlag in einem Projektmanagement Handbuch o. ä. Dieses bildet

dann für alle Projektverantwortlichen die verbindliche Guideline zur Vorgehensweise und

Methodik im Projekt. Würden sich die Verantwortlichen in einer Firma nun dazu ent-

scheiden, ihre Projekte nicht nur nach dem klassischen Ansatz abzuwickeln, sondern je

nach Projektart auch agiles oder hybrides Projektmanagement anzuwenden, würden sie

dadurch die ﬁrmeninterne Domäne des Projektmanagements erweitern.

Abb. 1.22 stellt die Dynamik zwischen Individuum, Feld und Domäne dar.

Feld

Domäne

Individuum, Team

• • •

Abb. 1.22 Drei Einﬂussfaktoren von Kreativität

1.8

Standards und Zertifizierungsmodelle im Projektmanagement

1.7.4

Rahmenbedingungen für Kreativität

Welche Konsequenzen haben diese Betrachtungen für das operative Projektmanagement?

Kreativität ist immer nur dann möglich, wenn ein Überschuss an Aufmerksamkeit vorhan-

den ist.

Projektteams sind prädestiniert dafür, einen Überschuss an Aufmerksamkeit zu ent-

wickeln für ein speziﬁsches Thema.

Die Arbeit am System (Abschn. 1.5.2) ist wesentlich: Das Projektteam muss so gut

wie möglich geschützt werden vor störenden Einﬂüssen aus der Stammorganisation

oder aus anderen Projekten, was die Aufmerksamkeit der einzelnen Personen verzettelt.

Je mehr eine Person parallel an mehreren Projekten arbeitet – und möglicherweise auch

noch Linienaufgaben hat – desto beschränkter ist die Aufmerksamkeit für eine speziﬁ-

sche Fragestellung. Das ist v. a. ein Problem in der Projektkoordination (Abschn. 2.3.9).

Kreativität fängt in den einzelnen Köpfen an und wird durch gute Kreativitätstechniken

(Abschn. 2.8) unterstützt.

Das Feld kontrolliert den Zugang zur Domäne: Damit spielen die Entscheidungsträger

in jeder Projektorganisation eine wesentliche Rolle: Linienvorgesetzte, Auftraggeber,

Projektleiter oder Product Owner: Wie gehen sie mit neuen Ideen um? Was sie zu-

rückweisen, ist verloren. Wer illusorische Ansätze verfolgt, verschwendet wertvolle

Ressourcen.

Welche Organisationskultur wird effektiv gelebt, welches Verhalten wird belohnt

(Abschn. 4.1.13)? Werden Projektverantwortliche ermutigt, neue Ideen einzubringen?

Was passiert, wenn etwas nicht funktioniert? Wie ist der Umgang mit dem Scheitern

(Abschn. 3.8.5)?

Professionelle Entscheidungstechniken (Abschn. 2.8.2), Risikomanagement (Abschn.

2.3.8) sowie die Steuerung der Erwartungshaltung der Anspruchsgruppen (Abschn.

2.3.5) sind integrale Bestandteile von nachhaltiger Kreativität.

1.8

Standards und Zertifizierungsmodelle im Projektmanagement

Im Markt existieren unterschiedliche Standards und Zertiﬁzierungsmodelle für das Pro-

jektmanagement. Die unterschiedlichen Standards fokussieren auf unterschiedliche The-

men wie Kompetenzen oder Projektmanagementprozessen. Auf internationaler Ebene gibt

es drei namhafte Zertiﬁzierungsmodelle: IPMA, PMI und PRINCE2. In der Schweiz ist

im Bereich der öffentlichen Verwaltung HERMES als Prozessmodell stark verbreitet.

Zusätzlich gibt es auch Normen, welche das Projektmanagement beschreiben und struk-

turieren.

Die verschiedenen Zertiﬁzierungsmodelle geben jeweils für ihr Modell einen Stan-

dard vor. Der Vorteil des Einsatzes eines Standards ist die gemeinsame Sprache und ein

gemeinsames Prozessframework in einem Unternehmen oder bei der unternehmensüber-

Einleitung

Tab. 1.9 Übersicht zu Zertiﬁzierungsmodellen

IPMA

PMI

Prince2

HERMES 5

Projektmitarbeiter

Certiﬁed Project Ma-

nagement Associate

(Level D)

CAPM

PRINCE2 2017

Foundation

HERMES 5 –

Foundation Level

Projektleiter

Certiﬁed Project

Manager (Level C)

Certiﬁed Project

Senior Manager

(Level B)

PMP,

PMI-ACP

PRINCE2 2017

Practitioner

PRINCE2 Agile

Practitioner

HERMES 5 –

Advanced Level

Projektdirektor,

Programm Mana-

ger und Portfolio

Manager

Certiﬁed Project

Director (Level A)

PgMP,

PfMP

greifenden Zusammenarbeit. Wenn jedoch ein Modell gewählt wird, welches nicht zum

Unternehmen passt, werden sich die Probleme in der Projektabwicklung vervielfachen.

Die von IPMA, PMI, Prince2 und Hermes angebotenen Zertiﬁzierungen werden in

Tab. 1.9 zusammengefasst.

Die Scrum Alliance bietet unterschiedliche Zertiﬁkate im Bereich Scrum an.

1.8.1

IPMA – International Project Management Association

IPMA ist weltweit verbreitet und hat europäischen Ursprung.

Für Personen bietet IPMA ein Zertiﬁkationssystem mit vier Levels an. Die Basis für

die Zertiﬁzierung bildet die Individual Competence Baseline (ICB).

Neben der Zertiﬁzierung von Personen bietet IPMA auch die Möglichkeit, Teams

nach Project Excellence Baseline und Organisationen mit der Organisational Compe-

tence Baseline zu zertiﬁzieren. Die Personenzertiﬁzierung auf Basis der ICB ist das

erfolgreichste Zertiﬁzierungsmodell von IPMA.

Die Zertiﬁzierungen werden durch die jeweiligen Länderorganisationen (Deutschland:

Deutsche Gesellschaft für Projektmanagement GPM, Schweiz: Verein zur Zertiﬁzierung

von Personen im Management VZPM und Österreich: Projekt Management Austria

PMA) angeboten und durchgeführt.

Bei der IPMA-Zertiﬁzierung geht es um den Nachweis von vorhandenen und ange-

wandten Kompetenzen. Dadurch unterscheidet sich IPMA wesentlich von den anderen

Zertiﬁzierungsmodellen, welche sehr prozessorientiert und auf die Anwendung eines de-

ﬁnierten Frameworks ausgelegt sind.

Die IPMA versteht unter individueller Kompetenz die Anwendung von Wissen, Fer-

tigkeiten und Fähigkeiten, um die gewünschten Ergebnisse zu erzielen. Fähigkeiten bauen

auf Fertigkeiten auf, welche wiederum Wissen voraussetzen:

1.8

Standards und Zertifizierungsmodelle im Projektmanagement

Tab. 1.10 IPMA-Zertiﬁzierungsbereiche und Zertiﬁzierungslevels

Domain

Level

Project

Programme

Portfolio

Certiﬁed Project Director

Certiﬁed Programme

Director

Certiﬁed Portfolio

Director

Certiﬁed Senior Project Manager

Certiﬁed Senior

Programme Manager

Certiﬁed Senior Port-

folio Manager

Certiﬁed Project Manager

Certiﬁed Project Management Associate

Wissen ist die Gesamtheit an Informationen und Erfahrungen, die eine Person besitzt.

Beispiel: Konzept eines Gantt-Diagramms erklären können

Fertigkeiten sind spezielle technische Fähigkeiten, mit deren Hilfe eine Person eine

Aufgabe ausführen kann.

Beispiel: Ein Gantt-Diagramm erstellen

Fähigkeiten beschreiben den effektiven Einsatz von Wissen und Fertigkeiten in einem

bestimmten Kontext.

Beispiel: Einen Projektablaufplan mit Gantt-Diagramm erstellen und damit erfolgreich

steuern

Das Herz der ICB bildet das „Eye of Competence“. Die Kompetenzen sind in

Abschn. 1.3.2 beschrieben.

Tab. 1.10 zeigt das Zertiﬁzierungssystem der IPMA für Personen.

In der Schweiz ist die Zertiﬁzierung auf Level D eine reine Wissensprüfung mit „open

book“. Für Zertiﬁzierungen auf den Levels B und C ist neben der Wissensprüfung auch der

Nachweis entsprechender Projekterfahrung und eines realisierten Projektes notwendig.

Dabei muss der Kandidat in einem schriftlichen Bericht und einem Interview nachweisen,

wie er die individuellen Kompetenzen in seinem Referenzprojekt angewandt hat. Auf dem

Level A entfällt die Wissensprüfung.

1.8.2

PMI – Project Management Institute

PMI ist ein weltweit etablierter Anbieter eines Zertiﬁzierungssystems. In den USA ist PMI

ein de facto Standard für die Abwicklung von Projekten.

Die Zertiﬁzierungen nimmt direkt PMI vor. Es gibt länderspeziﬁsche Chapters, welche

dem Networking und der Verbreitung der PMI Methoden dienen.

Die Zertiﬁzierungen basieren auf dem PMBOK® Guide (Project Management Body of

Knowledge). Für agile Vorgehensweisen bietet das PMI einen ergänzenden „Agile Prac-

tice Guide“ an.

Einleitung

Der PMBOK® Guide beschreibt neben organisatorischen Einﬂüssen auf das Projekt-

management einen Projektablauf mit vier Phasen. Der PMBOK® Guide strukturiert den

Projektablauf in fünf Prozessgruppen:

Initiating Process Group (Initialisierung)

Planning Process Group (Planung)

Executing Process Group (Ausführung)

Monitoring and Controlling Process Group (Überwachung und Steuerung)

Closing Process Group (Abschluss)

Zu den Prozessgruppen deﬁniert der PMBOK® Guide in der 6. Edition 2017 insgesamt

10 Wissensgebiete (siehe Tab. 1.11).

Ein Wissensgebiet (bspw. Projekt Risikomanagement) wird in einzelne Prozesse (z. B.

Risiken identiﬁzieren) aufgeteilt. Für jeden Prozess werden ein Eingangs- und ein Aus-

ganswert deﬁniert und die möglichen Werkzeuge und Methoden beschrieben. Dadurch

stellt der PMBOK® Guide ein umfassendes prozessorientiertes Methodenset dar.

Das PMI bietet folgende acht Zertiﬁzierungsmöglichkeiten an:

CAPM, Certiﬁed Associate in Project Management

PMP, Project Management Professional

PgMP, Program Management Professional

PfMP, Portfolio Management Professional

PMI-PBA, PMI Professional in Business Analysis

PMI-ACP, PMI Agile Certiﬁed Practitioner

PMI-RMP, PMI Risk Management Professional

PMI-SP, PMI Scheduling Professional

Die Zertiﬁzierung erfolgt mittels einer Multiple Choice Prüfung (closed book) und

basiert auf dem PMBOK® Guide.

1.8.3

PRINCE2

PRINCE2 ist in Großbritannien ein de facto Standard für die Abwicklung von Projekten.

Prince2 steht für „Projects in Controlled Environment“.

PRINCE2 wurde ursprünglich von der britischen Regierung entwickelt. Heute wird

PRINCE2 von der Firma AXELOS Ltd. angeboten.

PRINCE2 ist ein sehr detailliertes und integriertes Prozessmodell, welches genau fest-

legt, was von Projektbeginn bis zum Ende im Projekt gemacht werden muss. PRINCE2

fokussiert auf das zur Verfügung gestellte Framework. Es geht weniger um ein Methoden-

set oder um Kompetenzen. Abb. 1.23 zeigt das Projektmanagementsystem von Prince2,

bestehend aus Grundprinzipien, Themen und Prozessen.

1.8

Standards und Zertifizierungsmodelle im Projektmanagement

Tab. 1.11 Auszug aus den Projektmanagementprozessen (Wissensgebiete und Prozessgruppen, beginnt mit 4. Project Integration Management)

Wissensgebiete

Projektmanagement-Prozessgruppen

Initierungsprozess-

gruppe

Planungsprozessgruppe

Ausführungsprozess-

gruppe

Überwachungs und

Steuerungsprozess-

gruppe

Abschlussprozess-

gruppe

4. Integrations-

management in

Projekten

4.1 Projektauftrag

entwickeln

4.2 Projektmanagementplan

entwickeln

4.3 Projektdurch-

führung lenken und

managen

4.4 Projektwissen ma-

nagen

4.5 Projektarbeit über-

wachen und steuern

4.6 Integrierte Än-

derungssteuerung

durchführen

4.7 Projekt oder

Phase abschließen

5. Inhalts- und Um-

fangsmanagement in

Projekten

5.1 Inhalts- und Umfangsma-

nagement planen

5.2 Anforderungen planen

5.3 Inhalt und Umfang

deﬁnieren

5.4 Projektstrukturplan

erstellen

5.5 Inhalt und Umfang

validieren

5.6 Inhalt und Umfang

steuern

6. Terminplanungs-

management in

Projekten

6.1 Terminmanagement

planen

6.2 Vorgänge deﬁnieren

6.3 Vorgangsfolge festlegen

6.4 Vorgangsdauer schätzen

6.5 Terminplan entwickeln

6.6 Terminplan steuern

7. Kostenmanage-

ment in Projekten

7.1 Kostenmanagement

planen

7.2 Kosten schätzen

7.3 Budget festlegen

7.4 Kosten steuern

8. Qualitätsmanage-

ment in Projekten

8.1 Qualitätsmanagement

planen

8.2 Qualität managen

8.3 Qualität lenken

Einleitung

Pro

ject

viro

ent

Progress

Change

Risk

Plans

Quality

Organization

Business case

PRINCE 2 processes

PRINC

E 2 pri

nciple

PRINC

E 2 the

mes

Abb. 1.23 Übersicht Prince2 Modell

Die sieben Grundprinzipien von PRINCE2 lauten:

Fortlaufende geschäftliche Rechtfertigung

Lerne aus Erfahrung

Deﬁnierte Rollen und Verantwortlichkeiten

Steuern über Managementphasen

Steuern nach dem Ausnahmeprinzip

Produktorientierung

Anpassen an die Projektumgebung

Die sieben Themen von PRINCE2 lauten:

Business Case (Wozu?)

Organisation (Wer?)

Qualität (Was?)

Pläne (Wie?/Wie viel?/Wann?)

Risiken (Was ist, wenn?)

Änderungen (Was sind die Auswirkungen?)

Fortschritt (Wo stehen wir?/Wie geht es weiter?/Fortfahren?)

1.8

Standards und Zertifizierungsmodelle im Projektmanagement

Die sieben Prozesse von PRINCE2 lauten:

Projekt vorbereiten

Projekt lenken

Projekt initiieren

Eine Phase steuern

Produktlieferung managen

Phasenübergang managen

Projekt abschließen

Für PRINCE2 werden folgende Zertiﬁzierungen angeboten:

PRINCE2 2017 Foundation

PRINCE2 2017 Practitioner

PRINCE2 2017 Agile Practitioner

Die Zertiﬁzierung erfolgt mittels einer Multiple Choice Prüfung (open book) und ba-

siert auf dem jeweils aktuellen PRINCE2 Manual.

1.8.4

HERMES

HERMES ist die Projektmanagementmethode für öffentliche Verwaltungen in der

Schweiz. HERMES unterstützt die Steuerung, Führung und Ausführung von Projek-

ten verschiedener Charakteristiken und Komplexität. So genannte Szenarien stehen

kostenlos zur Verfügung für IT-Individualanwendung klassisch und agil, IT-Standar-

danwendung, IT-Anwendung Weiterentwicklung, IT-Infrastruktur, Entwicklung von

Dienstleistung/Produkt klassisch und agil sowie Organisationsanpassung.

Ein Szenario besteht aus Modulen. Ein Modul enthält die thematisch zusammenge-

hörenden Aufgaben, Ergebnisse und Rollen. Sie sind den Phasen und Meilensteinen

zugeordnet.

Für HERMES werden folgende Zertiﬁzierungen angeboten:

HERMES 5 – Foundation Level für Projektmitarbeiter (Prüfung: Multiple Choice)

HERMES 5 – Advanced Level für Projektleiter (Prüfung mit Multiple Choice und of-

fenen Fragen)

1.8.5

Scrum Alliance

Das Ziel der Scrum Alliance ist es, Scrum weiter zu etablieren. Dazu bietet die Scrum

Alliance Zertiﬁzierungen für Scrum an:

Einleitung

Certiﬁed Scrum Master

Certiﬁed Scrum Product Owner

Certiﬁed Scrum Developer

Darauf aufbauend kann die Zertiﬁzierung zum Certiﬁed Scrum Professional abge-

schlossen werden.

1.8.6

DIN 69901 und ISO 21500

In Deutschland existiert mit der DIN 69901 eine Reihe von Normen zur Standardisierung

des Projektmanagements:

DIN 69901-1 Grundlagen

DIN 69901-2 Prozesse, Prozessmodell

DIN 69901-3 Methoden

DIN 69901-4 Daten, Datenmodell

DIN 69901-5 Begriffe

Auf internationaler Ebene existiert die Norm ISO 21500 „Leitfaden zum Projekt-

management“, welche Begriffe, Grundlagen, Prozesse und Prozessmodell im Projekt-

management beschreibt.

Beide Normen repräsentieren eher die klassische Sicht auf das Projektmanagement

und geben bezüglich des Vorgehensmodells keine klaren Empfehlungen. Agiles Projekt-

management ist bis zur Drucklegung dieses Buches noch nicht in die Normen eingeﬂos-

sen.

1.9

Projektportfolio-, Multiprojekt- und Programmmanagement

Viele Organisationen leiden unter einem Projektboom, welcher die zur Verfügung stehen-

den Ressourcen völlig verzettelt. Aus nicht immer nachvollziehbaren Beweggründen wird

aus allen Problemstellungen ein Projekt gemacht, oder die simple Problemlösung wird

Projekt genannt. Oftmals hat dies damit zu tun, dass sich viele Führungskräfte überfordert

fühlen mit schwerwiegenden oder unangenehmen Führungsentscheiden. Sie delegieren

diese an ein Projekt oder lassen offen, nach welchen Kriterien etwas aus der Stammorga-

nisation in ein Projekt herausgelöst werden soll.

Das Management der Projekte wird vielfach unterschätzt. Eine Übersicht aller im Ge-

samtunternehmen laufenden Projekte fehlt oder ist nur mangelhaft vorhanden. Damit ist

weder eine Priorisierung der einzelnen Vorhaben möglich, noch können die vorhande-

nen Ressourcen zielgerichtet eingesetzt werden. Als Übersicht und Entscheidungshilfe

Literatur

kann hier ein Projektportfolio Unterstützung leisten. Das Portfoliomanagement wird in

der Praxis auch Multiprojektmanagement genannt. Für die Umsetzung von strategischen

Initiativen kann es auch hilfreich sein, Projekte in einem Programm zu bündeln. Diese

unterschiedlichen Themen können wie folgt gegeneinander abgegrenzt werden:

Projektportfolio-

management = Multi-

projektmanagement

– Strategisch orientierte und Abhängigkeiten zwischen Projekten be-

rücksichtigende Lenkung aller Projekte eines Unternehmens oder eines

Unternehmensbereichs.

– Ein Projektportfolio besteht aus Einzelprojekten und/oder Programmen.

– Ein Projektportfolio ist zeitlich unbegrenzt.

– Konﬁguration, Priorisierung und Kontrolle von Projektportfolios, um

die richtigen Dinge zu tun.

Programm-

management

– Dient der Umsetzung von ausgewählten strategischen Initiativen und

Zielen.

– Setzt sich aus der Umsetzung verschiedener Projekte zusammen.

– Dauert solange, bis die strategischen Initiativen umgesetzt und die stra-

tegischen Ziele erreicht sind. Ein Programm ist somit zeitlich begrenzt.

– Nach Beendigung des Programms wird auch die temporäre Struktur des

Programmmanagements abgebaut.

Projektmanagement

– Projektmanagement wird für Gestaltung, Lenkung und Controlling von

einzelnen Projekten eingesetzt: die Dinge richtig tun.

Der Schwerpunkt des vorliegenden Buches liegt auf dem Projektmanagement. Die

Themen Projektportfolio- und Programmmanagement werden im Abschn. 2.7 weiter ver-

tieft.

Literatur

Beck Kent, Schwaber Ken, Sutherland Jeff und weitere. (2001) Manifesto for Agile Software De-

velopment. http://agilemanifesto.org/

Csikszentmihalyi, Mihaly. (1997, 2. Auﬂage, 2015). Flow und Kreativität. Stuttgart: Klett-Cotta.

Dierig, S. (2015). Projektkompetenz im Unternehmen entwickeln. Berlin: Wissenschaftlicher Verlag

Berlin.

Doppler, Klaus & Lauterburg, Christoph. (1994, 13. Auﬂage 2014) Change Management, den Un-

ternehmenswandel gestalten. Frankfurt: Campus

Königswieser, R., & Hillebrand, M. (2004). Einführung in die systemische Organisationsberatung.

Heidelberg: Carl-Auer-Systeme Verlag.

Königswieser, R., Sonuc, E., & Gebhardt, J. (2008). Komplementärberatung. Das Zusammenspiel

von Fach- und Prozeß-Know-how. Stuttgart: Klett-Cotta.

Kotter, J.P (2012). Leading Change: Wie Sie Ihr Unternehmen in acht Schritten erfolgreich verän-

dern. München: Vahlen Verlag.

Lück, NZZaS, 11.3.2018

Oestereich, B., & Schröder, C. (2017). München: Verlag Franz Vahlen GmbH.

Petersen, Dominik, Witschi, Urs; Kötter, Wolfgang & Bahlow, Jörg. (2011). Den Wandel verändern.

Change-Management anders gesehen. Wiesbaden: Gabler Verlag | Springer Fachmedien

Einleitung

Pﬂaeging, Niels & Hermann, Silke. (2015). Komplexithoden. Clevere Wege zur (Wieder)Belebung

von Unternehmen und Arbeit in Komplexität. München: Redline

Project Management Institute, (2017). PMBOK® Guide in der 6. Edition

Seliger, Ruth (2008). Das Dschungelbuch der Führung (5. Auﬂage, 2014 Ausg.). Heidelberg: Carl-

Auer Verlag GmbH.

Wohland, Gerhard & Huther-Fries, Judith & Wiemeyer, Matthias & Wilmes, Jörg (2004): Vom Wis-

sen zum Können. Merkmale dynamikrobuster Höchstleistung. Eine empirische Untersuchung

auf systemtheoretischer Basis. Eschborn: Detecon & Diebold Consultants

Methodik

2.1

Einführung

2.1.1

Klassisch, agil und hybrid

Kap. 1 gibt eine kurze Einführung in die klassische, agile und hybride Vorgehensweise

im Projektmanagement. In der klassischen Vorgehensweise wird ein Projekt in Phasen

unterteilt; das Ergebnis liegt bei Ende des Projekts vor. In der agilen Vorgehensweise

werden Teilergebnisse fortlaufend erstellt.

Bei genauerer Betrachtung durchläuft auch eine agile Vorgehensweise wie Scrum ei-

ne verkürzte Konzeptphase, eine Realisierungs- und Einführungsphase. Die Aufgaben der

Initialisierung werden in der agilen Vorgehensweise vor oder oft zusammen mit der Erstel-

lung der Produktvision, des Product Backlogs und des Release-Plans in der Konzeptphase

erledigt.

Die wichtigste Phase in der agilen Methode ist die Realisierungsphase. Nach einer

deﬁnierten Anzahl Sprints wird ein Release produktiv gesetzt. Diese Produktivsetzung ist

durchaus mit der Einführungsphase in der klassischen Vorgehensweise vergleichbar.

Im vorliegenden Handbuch Projektmanagement werden die klassische und agile Vorge-

hensweise nicht getrennt behandelt. Im Sinne des hybriden Projektmanagements werden

die Elemente der klassischen und der agilen Vorgehensweise anhand der Phasen des klas-

sischen Projektmanagements (Projektbeauftragung, Initialisierung, Konzept, Realisierung

und Einführung) erklärt und vertieft. Das hybride Projektmanagement lässt offen, wie die

Teile der klassischen und agilen Vorgehensweise miteinander kombiniert werden. Situativ

muss entschieden werden, welche der Kombinationsmöglichkeiten im hybriden Pro-

jektmanagement angewendet werden soll:

J. Kuster et al., Handbuch Projektmanagement, https://doi.org/10.1007/978-3-662-57878-0_2

Methodik

Projektmanagement-Kompass

Vorbereitungsphase

0 Beauftragung

Projektphasen

1 Initialisierung

Nutzungsphase

(basierend auf Scrum)

Schwerpunkt

Idee

Projektziele (WAS)

Projektteam konstituieren

Risikomanagement

Erste Risikobetrachtung

Risiken auflisten

Planung

Machbarkeit, Wirtschaftlichkeit,

Controlling

Information &

Projekthandbuch aufsetzen

Kommunikation

Ergebnisse

Projektsteckbrief (1-Pager)

Projektauftrag

Business Case

Stakeholder-Analyse

Projektantrag

Risikoliste

Schwerpunkt

Idee

Projektziele / Lastenheft (WAS)

Projektstrukturierung, Grobplanung

Projektteam konstituieren

Risikomanagement

Erste Risikobetrachtung

Risiken identifizieren

Planung

Machbarkeit, Wirtschaftlichkeit,

Projektstrukturierung

Phasen- und Meilensteinplan

Projektstrukturplan

Controlling

Projektstatus Meeting

Projektausschuss konstituieren

Information &

Kommunikation

Projekthandbuch aufsetzen

Ergebnisse

Projektsteckbrief (1-Pager)

Projektauftrag

Business Case

Lastenheft

Projektantrag

Stakeholder-Analyse

Risikoliste

Projektplan (Meilenstein-

und Projektstrukturplan)

Lieferobjekte

Abb. 2.1 Kompass für die klassische und agile Vorgehensweise

2.1

Einführung

2 Konzept

3 Realisierung

Produktkonzept (WAS)

Umsetzung (Sprints)

Abnahme

Risiken bewerten

Massnahmen vereinbaren

Releaseplanung

Sprintplanung

Aktualisierung Releaseplan

Daily Standup Meeting

Sprint Review

Burndown Charts (Release, Sprint)

Standup Meeting

Daily Standup Meeting

Retrospektive

Produktkonzept

Sprint Backlog

Abnahmeprotokoll

Product Backlog

aktualisierter Releaseplan

Projektabschluss

Releaseplan

Inkrement

Lessons Learned

Testkonzept

Umsetzung (Entwicklung, Bau,

Serieproduktion (Produkt)

Detailplanung

Konstruktion, etc.)

Inbetriebnahme (Anlage)

Test

Produktivsetzung (Software)

Risiken bewerten

Massnahmen vereinbaren

Detailplanung

Termin- und Kostenplanung

Change Request Management

Ressourceneinsatzplanung

Fortschrittskontrolle

Korrekturmassnahmen

Steuerungsgruppe

Projektstatus Meeting

Reporting

Pflichtenheft

Testberichte

Serienfreigabe (Produkt)

Termin- und Kostenplan

Konstruktionsfreigabe

Abnahmeprotokoll (Anlage)

Ressourceneinsatzplan

Inhaltliche Ergebnisse

Projektabschluss

Risk Management Tool

Lessons Learned

Testkonzept, Betriebskonzept

Nutzung

Abb. 2.1 (Fortsetzung)

Methodik

Klassisch und agil abgewickelte Phasen

Klassisch und agil abgewickeltes Teilprojekt

Situative Kombination von Elementen aus der klassischen und agilen Vorgehensmetho-

de (z. B. Daily Standup Meeting und Retrospektive in der klassischen Vorgehensweise)

Fokus der klassischen und agilen Vorgehensweise in den einzelnen Phasen

Der Kompass in Abb. 2.1 gibt einen Überblick über die Schwerpunkte, Aktivitäten

(Risikomanagement, Planung, Controlling, Information und Kommunikation) und Er-

gebnisse in den einzelnen Phasen für die klassische und agile Vorgehensweise. In der

Übersicht zeigt sich deutlich, dass die Auseinandersetzung mit dem WAS und WIE in der

agilen Vorgehensweise erst zu einem späteren Zeitpunkt stattﬁndet als in der klassischen

Vorgehensweise.

Unterschiedliches Vorgehen in der Planung des Projektes

Die agile und die klassische Vorgehensweise verfolgen unterschiedliche Ansätze in der

Planung des Projektes.

In der agilen Vorgehensweise erfolgt in der Konzeptphase nur eine grobe Planung.

Da hier mit einem ﬁxen Team gearbeitet wird, vereinfacht sich die Ressourcen- und Kos-

tenplanung. Die Detailplanung wird erst unmittelbar vor der Umsetzung eines Sprints

durchgeführt. Die Planung in Scrum erfolgt auf drei Ebenen und ist als Übersicht in

Abb. 2.2 ersichtlich:

In der Release-Planung während der Konzeptphase werden folgende Punkte fest-

gelegt: Planung der Anzahl Sprints, Festlegung der provisorischen Reihenfolge der

Umsetzung der Anforderungen aus dem Product Backlog, Festlegung der Produktivset-

zungstermine von Releases.

Während des Sprint Plannings in der Realisierungsphase erfolgt die Planung der Ak-

tivitäten eines Sprints. Das Ergebnis wird im Sprint Backlog festgehalten.

Die Planung des Arbeitstages erfolgt im Daily Scrum.

In der klassischen Vorgehensweise erfolgt die Planung über mehrere Stufen. Nach-

dem in der Initialisierungsphase die Ziele und Anforderungen (Lastenheft) deﬁniert wur-

den, erfolgt die Projektstrukturierung (Grobplanung). Siehe Abb. 2.3, obere Zeile. Die

Projektstrukturierung enthält folgende Elemente:

Projektphasen und Meilensteine

Projektstrukturplan mit Teilprojekten, Lieferobjekten und Arbeitspaketen mit grober

Kostenschätzung

In der Konzeptphase werden zu den Anforderungen Lösungsvarianten ausgearbeitet.

Für die ausgewählte Lösungsvariante erfolgt eine detaillierte Ausarbeitung des Lösungs-

konzeptes. Basierend auf dem Lösungskonzept erfolgt die Detailplanung des Projektes.

Siehe Abb. 2.3, mittlere Zeile. Die Detailplanung enthält folgende Elemente:

2.1

Einführung

Konzept

Realisierung

Produkt-

konzept

Retro

Sprint Backlog

Sprint Planning

Releaseplan

Product

Backlog

Reﬁnement/

Grooming

Release

Einführung

•

Shipable

increment

Daily Scrum

Sprint Review

Abb. 2.2 Agile Projektplanung

Ablauf- und Terminplan

Ressourcenplan

Kostenplan

2.1.2

Genauigkeit von Schätzungen

Eine Schätzung ist eine provisorische oder vorläuﬁge Kalkulation. Der Kunde oder

das Management des Unternehmens erwartet aber eine möglichst verlässliche und zuver-

lässige Kostenschätzung.

In der agilen Vorgehensweise nimmt man diesen Umstand auf, indem die Dauer (Time-

boxing) und die Kosten des Projektes im Voraus ﬁx deﬁniert werden. Die Unsicherheit

liegt dann im effektiven Leistungsumfang (Scope), welcher realisiert wird.

In der klassischen Vorgehensweise wird der Leistungsumfang (Scope) ﬁxiert. Bei ein-

fachen Projekten und Standardprojekten ist die Schätzung der Zeitdauer und der Kosten

relativ zuverlässig. Bei großen Vorhaben, Pionier- oder Potentialprojekten ist die Schät-

zung der Zeitdauer und der Kosten mit vielen Unsicherheitsfaktoren behaftet und ent-

sprechend am Anfang ungenau. Die Ungenauigkeiten nehmen mit dem Zeitverlauf des

Methodik

Detailplanung

Terminplan

Kostenplan

Ressourcenplan

Konzepte

Pﬂichtenheft

Projektstrukturierung

Phasenplan / Teilprojekte / Projektstrukturplan

Ziele

Lastenheft

Multi-Projektmanagement

Abb. 2.3 Klassische Projektplanung, bestehend aus Projekt-Strukturierung und Detailplanung

Projektes und dem Fortschritt ab. Je nach Projektart muss in den Phasen mit folgenden

Toleranzen gerechnet werden:

Nach Projektbeauftragung: +100 %/50 % oder mehr

Nach Projektstrukturierung: +40 %/20 %

Nach Detailplanung: ˙10 %

2.1.3

Praxisbeispiele

Die behandelte Theorie wird anhand von zwei Beispielen von hybridem Projektmanage-

ment aus der Praxis unterlegt.

BLS AG

Die BLS gehört zu den größten Verkehrsunternehmen der Schweiz. Im Kerngeschäft

Bahn betreiben die BLS die Berner S-Bahn und damit das zweitgrößte S-Bahn-Netz

der Schweiz. Zudem fährt die BLS die westlichen Linien der S-Bahn Zentralschweiz.

Auch im touristischen Verkehr ist die BLS verankert. Zum Angebot zählen Bahnlinien

durch das Emmental, im Jura, im Seeland, im Simmental, nach Interlaken sowie über die

2.1

Einführung

Lötschberg-Bergstrecke. Die BLS ist tätig in den Bereichen Bus, Schiff, Autoverlad und

Güterverkehr:

Im Emmental betreibt die BLS mit dem Tochterunternehmen Busland AG ein Busnetz

aus 18 Linien.

Die BLS Schifffahrt auf dem Thuner- und dem Brienzersee ist ein Aushängeschild für

die Tourismusdestination Berner Oberland.

Der BLS Autoverlad am Lötschberg von Kandersteg nach Goppenstein bietet ganzjäh-

rig eine schnelle Verbindung von Bern ins Wallis. Mit dem Autoverlad von Brig nach

Iselle bietet die BLS auch eine Verbindung nach Italien an.

Das Tochterunternehmen BLS Cargo AG nimmt im Schienengüterverkehr durch die

Alpen eine zentrale Position ein.

Projekt Vertriebs-Back-End VBE

Zwei Entwicklungen im öV (öffentlicher Verkehr) lagen diesem Projektvorhaben zugrun-

de. Erstens wurden im Branchenprojekt ZPS (zukünftiges Preissystem öV-Schweiz) die

öV-Plattform und die zugehörige Standardschnittstelle NOVA entwickelt. Jedes Trans-

portunternehmen kann die eigenen Vertriebssysteme an diese Schnittstelle anschließen.

Um effektiv Tickets von der öV-Plattform verkaufen zu können, werden ein eigenes Ver-

triebs-Back-End und ein Front-End benötigt. Zweitens nimmt aufgrund der Markttrends

und der fortschreitenden Digitalisierung der Gesellschaft die Bedeutung des digitalen Ver-

triebs stark zu. Um diesem Trend sowie den zugrunde liegenden Bedürfnissen gerecht zu

werden und ihre Kundenorientierung zu stärken, muss die BLS ihre Kunden über das In-

ternet wie auch über einen mobilen Kanal bedienen können.

Methodik

Das Projekt VBE führte diese beiden Entwicklungen zusammen und hatte zum Ziel, bis

Ende 2016 ein eigenes, unabhängiges und mandantenfähiges Vertriebs-Back-End inklusi-

ve einer mobilen Lösung und einem online Vertriebskanal, basierend auf dem zukünftigen

Branchenstandard öV-Plattform/NOVA, zu realisieren.

Metrohm AG

Die Metrohm AG ist einer der weltweit größten Hersteller von Hochpräzisionsinstrumen-

ten für die chemische Analytik und wurde 1943 von Ingenieur Bertold Suhner in Herisau,

Schweiz, gegründet. Vom Start-up hat es Metrohm zum Global Player geschafft und ist

heute mit gut 2200 Mitarbeitern in mehr als 80 Ländern mit eigenen Tochtergesellschaf-

ten und exklusiven Vertriebspartnern präsent. Als weltweiter Marktführer für analytische

Geräte im Titrationsbereich entwickelt Metrohm Lösungen für sämtliche Aufgabenstel-

lungen der Ionenanalytik.

Projekt OMNIS Titriersystem

Im OMNIS Projekt wurde ein voll integriertes Titrationssytem entwickelt, welches die

Bedürfnisse des heutigen Labors adressiert und schnellere Ergebnisse mit mehr Sicherheit,

Komfort und Efﬁzienz liefert. Das voll integrierte System umfasste neben dem Titrator

auch Liquid Handling Module, eine neue Software und einen neuen Proberoboter.

OMNIS bietet Leistung auf einem ganz neuen Level und hat dabei die Antworten auf

die wachsenden Anforderungen im alltäglichen Laborbetrieb:

2.2

Phase Projektbeauftragung

Vervierfachung des Probendurchsatzes: Mit ein und demselben System können vier

Analysen gleichzeitig und vollautomatisch durchgeführt werden.

Berührungsfreies Chemikalienhandling: Dank der patentierten 3S-Adaptertechnologie

muss keine Flasche beim Reagenzwechsel geöffnet werden.

Eine Analyseplattform, die jeder beherrscht: Durch eine intuitive Systemführung, kann

OMNIS nahezu von allen Anwendern bedient werden.

Das OMNIS Titrierplattform Projekt wurde sechs Jahre vor der geplanten Marktfreiga-

be gestartet.

2.2

Phase Projektbeauftragung

Geänderte Marktbedingungen, Kundenwünsche und der Druck, Efﬁzienzgewinne reali-

sieren zu müssen, zwingen Unternehmen dazu, laufend Projekte umzusetzen. Meist gibt

es mehr Wünsche für neue Projekte, als was ein Unternehmen sich leisten kann. Die Pro-

jektidee muss es in der Phase der Projektbeauftragung schaffen, ins Portfolio der Projekte

(Abschn. 2.7) aufgenommen zu werden.

Auftraggeber und weitere Mitarbeiter (z. B. Portfoliomanager, Produktmanager oder

Projektleiter) klären ab, ob ein neues Vorhaben projektwürdig ist. Dazu wird ein Projekt-

steckbrief und ein Business Case (Abschn. 2.2.3) erarbeitet und in die Projektportfolio-

Diskussion aufgenommen. Der Projektsteckbrief klärt die wichtigsten Eckdaten der Pro-

jektidee: Ziele, zu schaffender Mehrwert, grobe Zeit- und Budgetvorstellung, Bezug zur

Strategie. Der Business Case klärt die strategische Relevanz, den Nutzen und die Wirt-

schaftlichkeit. In dieser Phase wird das Projekt noch nicht konkret geplant, aber es wer-

den genügend Eckdaten zusammengetragen, damit die Unternehmensführung entscheiden

kann, welche Projekte umgesetzt werden sollen und welche nicht. Idealerweise wird in

dieser Phase auch der Projektleiter, der Product Owner oder Scrum Master ernannt. Zum

Schluss der Phase wird der Projektantrag zur Planung der Initialisierungsphase erstellt.

In dieser Phase gibt es keine speziﬁschen Unterscheidungen zwischen Projekten, die

agil oder klassisch abgewickelt werden.

Für kleine Projekte und Auftragsabwicklungsprojekte kann diese Phase gekürzt oder

übersprungen werden.

2.2.1

Worauf kommt es in der Phase Beauftragung an?

Schritte der Phase Projektbeauftragung

Tab. 2.1 zeigt die wichtigsten Schritte in der Phase Projektbeauftragung.

Methodik

Tab. 2.1 Schritte der Phase Projektbeauftragung

Arbeitsschritt

Beschreibung

Projektwürdigkeit

überprüfen

(Abschn. 1.2.3)

Für den Entscheid, ob ein Vorhaben als Auftrag innerhalb der Linie abgewi-

ckelt werden soll oder als übergreifendes Projekt durchzuführen ist, gelten

folgende Kriterien:

– Sind andere Bereiche betroffen?

– Welche Bereiche müssen wie viele Ressourcen beisteuern?

– Welche Bedeutung und Konsequenzen hat das Vorhaben für die Zukunft

des Unternehmens?

– Welche Risiken bestehen?

– Was geschieht, wenn das Vorhaben gestoppt wird?

Projektsteckbrief

und Business Case

schriftlich festhal-

ten

Projektsteckbrief und Business Case erarbeiten. Diese Dokumente sind Ent-

scheidungsgrundlage für den Grundsatzentscheid, ob das Projekt umgesetzt

werden soll oder nicht.

Planung: erste

Grobschätzung

Schon sehr früh, sobald eine Idee erste Formen annimmt, wird sich der Pro-

jektinitiant überlegen, wie viel Aufwand die Umsetzung der Idee benötigt

und was es dazu sonst noch braucht.

In dieser Phase kann nicht von Planung gesprochen werden, sondern von

Grobschätzung. Die Unsicherheit einer Grobschätzung kann sehr stark

schwanken, z. B. +100 %/50 %. Bei Projekten mit hohem Neuigkeitswert

kann sie noch größer sein (vergleiche auch Abschn. 1.2.1).

Wird eine projektwürdige Idee weiter abgeklärt, und es entsteht daraus ein

Projektsteckbrief und ein Business Case, will der Auftraggeber eine Grob-

schätzung der benötigten Mittel. Er will wissen, bis wann das Projekt zu

welchem Aufwand abgeschlossen ist und bis wann Zwischenresultate zu

erwarten sind.

Erarbeitung Pro-

jektantrag/Planung

der nächsten Phase

(Initialisierung)

Wenn der Entscheid für die Durchführung des Projektes gefällt ist, gilt es,

den Projektantrag zu erarbeiten und dabei folgende Fragen zu beantworten:

– Welche Resultate müssen am Ende der Initialisierungsphase erreicht

sein?

– Welche Zwischenziele müssen bis wann erreicht sein, um den terminge-

rechten Abschluss der Initialisierungsphase zu ermöglichen?

– Gibt es spezielle Risiken oder Probleme, die abzuklären sind? Muss eine

Risikoanalyse oder eine Machbarkeitsstudie durchgeführt werden?

– Wie müssen die Arbeitsschwerpunkte in dieser Phase gelegt werden, um

die Ressourcen optimal zu nutzen?

– Welches spezielle Know-how wird dazu benötigt?

– Wo ist der Einsatz von Engpassressourcen erforderlich?

– Wer steht zur Verfügung? Mit welchen Erfahrungen? Ist schon eine ver-

bindliche Zusage der Linienorganisation vorhanden?

– Muss eine Tätigkeit früher initialisiert werden, weil sie eine überlange

Durchlaufzeit hat?

– Welche internen und externen Kosten fallen in der nächsten Phase an?

2.2

Phase Projektbeauftragung

Tab. 2.2 Ergebnisse der Phase Projektbeauftragung

Zu beantwortende

Fragen

– Ist das Projekt mit den verfügbaren Ressourcen zusätzlich zum beschlos-

senen Projektportfolio durchführbar?

– Lohnt sich die Durchführung dieses Projektes unter Berücksichtigung von

Aufwand und erwartetem Nutzen?

Prozessorientierte

Ergebnisse

– Projektsteckbrief

– Projektantrag für die Phase Initialisierung

Inhaltsorientierte

Ergebnisse

– Business Case: Überlegungen, ob das Projekt aus Sicht des Marktes, der

Unternehmensstrategie usw. wirtschaftlich und sinnvoll ist

– Je nach Projektart und Situation: Erste Machbarkeitsabschätzungen, grobe

Ressourcenabstimmung, grundsätzliche Finanzierbarkeit

Ergebnisse der Phase der Projektbeauftragung

In der Phase der Projektbeauftragung ist das Projekt meist noch nicht öffentlich. Das heißt,

die Kommunikation beschränkt sich auf eine sehr kleine Anzahl von involvierten Personen

oder Gremien. Besonders in diesem Kreis muss die Kommunikation sehr sorgfältig ge-

staltet werden. Die Entscheidungsträger müssen sich bei strategisch wichtigen Projekten

damit auseinandersetzen, ob sie nach außen den Willen für dieses Projekt zeigen wol-

len oder ob strikte Geheimhaltung gelten soll, z. B. bei Entwicklungsprojekten. In dieser

Phase geht es darum zu entscheiden, ob das Projekt umgesetzt werden soll oder nicht,

beziehungsweise ob die nächste Stufe der Konkretisierung ausgearbeitet werden soll. Die

Ergebnisse der Phase Projektbeauftragung sind in Tab. 2.2 dargestellt.

Mensch und Team

Folgende Aspekte aus den Kompetenzbereichen Mensch und Team können in dieser Pro-

jektphase relevant sein. Es ist aber auch möglich, dass sie in einer späteren Phase oder gar

nicht auftreten.

In dieser ersten Projektphase wird meistens ein informelles Team geschaffen, welches

die notwendige technische und methodische Expertise hat, um die kritischen Erfolgs-

faktoren der Projektidee zu identiﬁzieren und um Business Case und Projektantrag zu

formulieren. Folgende Maßnahmen und Kompetenzen sind wichtig.

Laterale Führung (Abschn. 4.1.13.2): Meist wird in dieser Phase nicht eine formale

Organisation gebildet, sondern es wird ein Koordinator eingesetzt, der sein Team lateral

führt.

Arbeit im System (Abschn. 1.5.1 und 4.2.4): Die inhaltliche Arbeit steht im Vorder-

grund.

Vielseitigkeit und Kreativität (Abschn. 1.7): Von Anfang an sollten unterschiedliche

Varianten und Szenarien beleuchtet werden.

Informelles Netzwerk (Abschn. 4.1.3.3): Der Projektverantwortliche hat in diesem Sta-

dium noch kein ofﬁzielles Mandat. Wie effektiv er in dieser Situation seinen Auftrag

erfüllen kann, hängt stark von seinem informellen Netzwerk ab.

Methodik

2.2.2

Projektsteckbrief

Im Projektsteckbrief (1-Pager) wird die Idee für ein Projekt strukturiert erfasst und kon-

kretisiert. Der Projektsteckbrief sollte kurz abgefasst sein und Aussagen zu folgenden

Inhalten enthalten:

Projektname

Strategischer Bezug

Kurze Beschreibung

Kurze Historie (wie kommt es zum Projekt, welche Vorleistungen gibt es?)

Erwarteter Mehrwert/Nutzen/Erlös (aus dem Business Case)

Erwartete Kosten (aus dem Business Case), grober Ressourcenbedarf

Geschätztes Start- und Enddatum

Benennung zentraler Projektrollen (Auftraggeber, Projektleiter oder Product Ow-

ner/Scrum Master)

Bekannte Abhängigkeiten

Erste Risikobetrachtung

Der Projektsteckbrief dient zusammen mit dem Business Case als Basis für die Ent-

scheidung, ob die formulierte Idee weiterverfolgt werden und ein konkretes Projekt ge-

startet werden soll. Jedes Unternehmen ist bezüglich dieser Entscheidungsﬁndung anders

organisiert und aufgestellt. Typischerweise werden solche Entscheidungen anlässlich der

strategischen Planung, Projektportfolioplanung oder einer Mehrjahres- oder Budgetpla-

nung gefällt. Auch das Gremium, in welchem solche Entscheide gefällt werden, variiert:

Geschäftsleitung, Portfolioboard.

Bei Auftragsabwicklungsprojekten kann der Projektsteckbrief auch der Offerte, be-

ziehungsweise der Bestellung des Kunden entsprechen, eventuell ergänzt mit unterneh-

mensinternen Anforderungen.

2.2.3

Business Case

Organisationen leben davon, dass sie Nutzen stiften. Darum stellt sich die Frage nach

dem Nutzen einer Projektidee sehr früh. Überleben kann eine Organisation in unserem

Wirtschaftssystem, wenn sie Geld zur Verfügung hat. Jedes geplante Projekt muss darauf

geprüft werden, ob es die Chancen der Überlebensfähigkeit der Organisation verbessert.

Ob ein Projekt in Angriff genommen werden soll, ist vor der Auftragsvergabe durch

den Auftraggeber oder das entsprechende Gremium zu beurteilen. Dabei spielen nicht

nur quantiﬁzierbare Geldwerte, sondern auch strategische Überlegungen, Philosophien,

Ressourcen usw. eine Rolle.

Viele Organisationen verlangen im Vorfeld eines Projektes zusammen mit dem Pro-

jektsteckbrief einen Business Case mit folgendem Inhalt:

2.2

Phase Projektbeauftragung

Problemstellung und Begründung des Vorhabens

SWOT-Analyse

Kundenbedürfnisse und Marktpotential

Rahmenbedingungen

Wettbewerbsposition

Strategische Relevanz, Beitrag zur Erreichung von strategischen Zielen (Strategie-

Alignment)

Marketing Mix

Wirtschaftlichkeit (Erwarteter Mehrwert, Nutzen, Erlöse, Investitions- und Betriebs-

kosten, Ergebnis, Return on Investment)

Nicht-monetärer Nutzen für das Unternehmen

Auswirkungen bei einer Nicht-Durchführung

2.2.4

Projektantrag

Wenn ein Unternehmen aufgrund von Projektsteckbrief und Business Case entscheidet,

das Projekt durchzuführen, so ist in einem nächsten Schritt der Projektantrag für die Phase

Initialisierung zu erstellen.

Der Projektantrag entspricht in wesentlichen Teilen dem Projektauftrag. Der Projekt-

antrag betrachtet jedoch nur die Phase Initialisierung und nicht das ganze Projekt und

regelt diese Punkte:

Ziele für die Phase Initialisierung

Grundlagen (Auf welchen Vorarbeiten bzw. Grundlagen basiert das Projekt?)

Abgrenzungen (Projektgrenzen, Projektumfang)

Abhängigkeiten

Rahmenbedingungen

Ergebnisse und Lieferobjekte der Phase Initialisierung

Projektkosten und personelle Ressourcen für die Phase Initialisierung

Risiken

Projektplan für die Phase Initialisierung (Vorgehen und Terminplan)

Projektorganisation für die Phase Initialisierung

Unterschriften von Auftraggeber und Projektleiter/Product Owner

Einzelne Unternehmen legen Fokus und Inhalt des Projektantrags nicht nur auf die

Initialisierungsphase. Als Vorstufe für den Projektauftrag planen sie bereits das ganze Pro-

jekt grob. Sie schätzen auch die Gesamtkosten und die Folgekosten wie die Betriebskosten

ab.

Methodik

2.2.5

Checkliste Abschluss Projektbeauftragung

Wurde der Projektantrag erstellt?

Sind Projektwürdigkeit und Projektpriorität geklärt?

– Passt dieses Vorhaben in die Unternehmensstrategie?

– Ist dieses Vorhaben zwingend?

– Was sind die Konsequenzen bei Unterlassung?

Welche Position hat das Projekt im Portfolio?

Wurde eine Wirtschaftlichkeitsabschätzung mit realistischen Annahmen durch-

geführt?

Wurde der Business Case erstellt?

Wurde die Wahl des Vorgehensmodells gefällt: agil, klassisch, hybrid?

Wurde die Phase Initialisierung geplant: Ergebnisse, Zwischenziele, Ressourcen,

Termine, Mittel?

Wurde der Projektantrag freigegeben?

2.3

Phase Initialisierung

In der Phase Initialisierung sind in der klassischen Vorgehensweise verbindliche Aussa-

gen zu Machbarkeit, Risiken und Stakeholdern zu erarbeiten. Wesentliche Grundlagen

dazu sind die Analyse der aktuellen Situation sowie klar vereinbarte Ziele und die Formu-

lierung der Anforderungen.

Es ist ein erklärtes Anliegen, die Unsicherheiten und Risiken, die zu Beginn eines Pro-

jekts bestehen, so rasch und so weit wie möglich zu reduzieren. Gehen die Ziele und

Anforderungen an die Grenzen des Möglichen, oder ist das Mögliche nur ungenau be-

kannt (Technologiegrenze, politisch heikle Ziele), so ist es sinnvoll, vor der Durchführung

des ganzen Projektes eine Vorstudie (ähnliche Begriffe: Machbarkeitsstudie, Feasibility

Study, Vorprojekt) durchzuführen oder einen agilen Ansatz für die Projektdurchführung

zu wählen. Wenn sich zeigt, dass mit den eigenen Möglichkeiten eine Zielerreichung nicht

realistisch ist, drängt sich schon jetzt ein Projektabbruch auf. So wird vermieden, dass

wertvolle Ressourcen für ein aussichtsloses Projekt eingesetzt werden.

In der Initialisierungsphase wird der Projektauftrag verfasst. Darin sind die Ziele,

das Vorgehen, die Projektorganisation, Pläne und die Rahmenbedingungen für das Pro-

jekt festgehalten. Formal ist der Auftraggeber für den Projektauftrag verantwortlich. In

der Praxis arbeitet der Product Owner oder der Projektleiter das Dokument aus. So ist

es viel wahrscheinlicher, dass beide Parteien unter dem Gleichen das Gleiche verstehen.

Der Projektauftrag wird vom Auftraggeber und Product Owner/Projektleiter unterzeich-

net. Dieser Formalismus schützt das Unternehmen vor einer nicht zu bewältigenden Fülle

an Projekten und gibt dem Projektteam eine klare Ausrichtung.

2.3

Phase Initialisierung

In der agilen Vorgehensweise wird diese Phase sehr kurz ausfallen oder sogar über-

sprungen.

2.3.1

Worauf kommt es in der Phase Initialisierung an?

Schritte dieser Phase

Die Initialisierung ist in der klassischen Vorgehensweise sorgfältig durchzuführen: Die

Weichenstellungen dieser Phase haben die größten Auswirkungen. Siehe Abb. 2.4. Am

Anfang haben Projektentscheide oder Risikovorkehrungen (blau) großen Einﬂuss auf das

Projekt. Gegen Ende des Projekts sind die Kosten (rot) hoch, Entscheide haben aber darauf

nur noch wenig Einﬂuss. Oftmals wird die Initialisierung zu oberﬂächlich gemacht. Das

wird mit späterem zusätzlichem Zeit- und Ressourcenaufwand teuer bezahlt.

Das Projekt wird ofﬁziell gestartet, der Kick-off mit dem Projektteam durchgeführt.

Schließt die Initialisierung mit dem Antrag, das Projekt weiterzuführen, ist vom Ent-

scheidungsträger grünes Licht für den Fortgang des Projektes einzuholen. Im gegenteili-

gen Fall ist das Vorhaben zu beenden. Bisher erarbeitete Resultate sind so zu dokumen-

Relative Bedeutung

der Entscheide

Wissen

Projektkosten

Risiko

typ. Aufmerksamkeit

des Managements

Initialisierung

Konzept

Realisierung

Einführung

Zeit

klein

mittel

gross

Abb. 2.4 Einﬂussmöglichkeiten im Projekt

Methodik

Tab. 2.3 Schritte der Phase Initialisierung

Agile Vorgehensweise

Klassische Vorgehensweise

Wichtigste

Schritte

Ausgangslage und Problem klären

Ist-Zustand erheben und analysieren

Zielsetzung klären und festlegen

Stakeholder analysieren

Groben Projektauftrag ausarbeiten mit:

– Zielsetzung

– Vorgehensplan: Methoden, sehr grober

Terminplan

– Personalressourcen und Projektorgani-

sation

– Grobe Schätzung der Projektkosten

Risiken identiﬁzieren

Projekthandbuch verfassen

Spielregeln festlegen

Projekt Kick-off durchführen

Ausgangslage und Problem klären

Ist-Zustand erheben und analysieren

Zielsetzung klären und festlegen

Anforderungen (Lastenheft) deﬁnieren

Stakeholder analysieren

Machbarkeit prüfen

Detaillierten Projektauftrag ausarbeiten

mit:

– Zielsetzung

– Vorgehensplan: Methoden, Schritte,

Meilensteine, grober Terminplan, Pro-

jektstrukturplan

– Abhängigkeiten und Einﬂussgrößen

– Personalressourcen und Projektorgani-

sation

– Grobe Schätzung der Projektkosten

– Rahmenbedingungen und Abgrenzun-

gen

Risiken identiﬁzieren

Projekthandbuch verfassen

Spielregeln festlegen

Projekt Kick-off durchführen

tieren, dass sie bei Bedarf weiter verwendbar sind. Den Beteiligten ist für ihre Arbeit zu

danken. Der Einsatz zum Schutz der Ressourcen ist zu würdigen.

Früh in der Initialisierungsphase muss entschieden werden, ob das Projekt mit der klas-

sischen, agilen und hybriden Vorgehensweise umgesetzt werden soll. Tab. 2.3 zeigt die

wichtigsten Schritte der Initialisierungsphase in der agilen und klassischen Vorgehens-

weise.

Ergebnisse der Initialisierungsphase

In der Initialisierungsphase wird die Machbarkeit geprüft und damit abgeklärt, ob das

Projekt durchführbar ist und ob es einen ausreichenden Nutzen generieren wird. Reift

die Überzeugung, dass das Projekt gemacht werden muss, werden die nächste Phase und

das Projekt geplant. Je nach gewählter Vorgehensweise – klassisch, agil oder hybrid –

werden in dieser Phase die in Tab. 2.4 dargelegten Ergebnisse erstellt.

Sobald der Projektauftrag freigegeben ist, wird der Kick-off mit dem Projektteam

durchgeführt.

Kritische Erfolgsfaktoren und Key Performance Indikatoren

Das Konzept der kritischen Erfolgsfaktoren (KEF) kann auf der Ebene einer Unterneh-

mung, aber auch innerhalb eines Projektes angewandt werden. Unter KEF versteht man

2.3

Phase Initialisierung

Tab. 2.4 Ergebnisse der Phase Initialisierung

Phasen/

Tätigkeiten

Agile Vorgehensweise

Klassische Vorgehensweise

Grundsatz

In der agilen Vorgehensweise wird diese Phase sehr kurz

ausfallen. Es werden nur die groben Eckdaten aus der Phase

Beauftragung überprüft und gegebenenfalls konkretisiert. Die

Planung des Projektes ﬁndet mit der Erstellung des Release-

Plans in der Phase Konzept und in den jeweiligen Planungen

der einzelnen Iterationen der Realisierungsphase statt.

In der klassischen Vorgehensweise wird das Projekt umfassend

geplant. Dadurch können klare Aussagen zu Terminen, Kosten und

Ressourcen gemacht werden.

Zu beantwor-

tende Fragen

– Wer sind die relevanten Stakeholder?

– Wer ist Product Owner, Scrum Master und wie ist das Team

zusammengesetzt?

– Was sind die groben Eckwerte für das Projekt?

– Wie werden die Risiken eingeschätzt?

– Bis wann sind die Resultate oder Zwischenergebnisse zu erwar-

ten?

– Wie sieht die Planung für das Projekt aus?

– Wie groß wird der geschätzte Aufwand in Personentagen?

– Wieviel Geld soll über die gesamte Projektdauer investiert wer-

den?

– Wer sind die relevanten Stakeholder?

– Wer ist der Projektleiter?

– Wer sind die Teilprojektleiter?

– Wie ist das Team zusammengesetzt.

– Welche Engpassressourcen werden in welchem Zeitraum benö-

tigt?

– Wie werden die Risiken eingeschätzt?

Methodik

Tab. 2.4 (Fortsetzung)

Phasen/

Tätigkeiten

Agile Vorgehensweise

Klassische Vorgehensweise

Prozess-

orientierte

Ergebnisse

Projektauftrag als Dokument der Vereinbarung zweier Parteien:

– Vorgehensplan: Methoden, Schritte, Meilensteine, erster Termin-, Ressourcen- und Kostenplan (bei der klassischen Vorgehens-

weise in einer detaillierteren Form als bei der agilen Vorgehensweise)

– Projektorganisation

– Vorgehensplan der nächsten Phase

– Informations- und Kommunikationskonzept (unternehmensintern und -extern) und Spielregeln

Projekthandbuch/Projektmanagementplan

Risikoliste

Stakeholder-Analyse

Statusberichte, Protokolle

Antrag für die nächste Phase

Inhalts-

orientierte

Ergebnisse

In der agilen Vorgehensweise erfolgt erst in der Konzeptphase

die vertiefte inhaltliche Auseinandersetzung, um das Produkt-

konzept zu erstellen. Das heißt, in der Initialisierungsphase

werden keine inhaltlichen Themen erarbeitet. Allenfalls wird

die Machbarkeit geprüft.

Dokumente in der klassischen Vorgehensweise, welche die inhalt-

lichen Ergebnisse betreffen:

– Voraussetzungen und Annahmen

– Schwächen und Mängel des Ist-Zustandes

– Vertiefte Marktstudien, Umfragen, Mitarbeiterbefragungen usw.

– Überarbeitete, detaillierte Zielsetzung

– Anforderungen/Lastenheft

– Prüfung und Beurteilung der Machbarkeit, Kosten, Wirtschaft-

lichkeit, Risiken und detaillierte Wirtschaftlichkeitsrechnung

Konzept: in der Initialisierungsphase stehen Lösungskonzepte

noch nicht im Vordergrund. Hier sind Analyse-Ergebnisse und

Zielsetzungen entscheidender. Lösungen beschränken sich vorerst

auf Lösungsideen oder grobe Varianten.

2.3

Phase Initialisierung

die Faktoren und die Schlüsselgrößen, welche für die Erreichung der Zielsetzung des Pro-

jektes von zentraler Bedeutung sind. Die KEF eines Projektes stehen in direkter Beziehung

zu den KEF des Unternehmens. Der Product Owner oder Projektleiter muss in der Lage

sein, die KEF des Projektes auf die KEF der Unternehmung auszurichten. Die Auseinan-

dersetzung mit den KEF ist in der Initialisierungsphase wichtig, da dies hilft, das Projekt

effektiver auf die Zielerreichung auszurichten.

Kritische Erfolgsfaktoren in einem Projekt können sein:

Projektvorgehensweise

Projektstart

Projektorganisation und Besetzung der Rollen

Erfahrung der Schlüsselpersonen im Projekt

Motivation und Zusammenarbeit des Projektteams

Management des magischen Dreiecks von Scope, Zeit und Kosten

Stakeholder-Management

Risikomanagement

Agile oder klassische Projektplanung

Umgang mit Stress, Widerständen und Konﬂikten im Projektteam

Aufgrund der deﬁnierten KEF kann die Projektstrategie (Best in Market, Design to

Cost, Time to Market) (Abschn. 2.3.4) festgelegt werden.

Key Performance Indikatoren (KPI) sind Leistungsindikatoren. Sie helfen, laufend den

Projektfortschritt und den Zielerreichungsgrad zu messen und zu beurteilen. KPI dienen

dem Managen der KEF. Jeder kritische Erfolgsfaktor (KEF) hat einen oder mehrere KPI.

Mensch und Team

Die untenstehenden Aspekte aus den Kompetenzbereichen Mensch und Team können in

dieser Projektphase relevant sein. Es ist aber auch möglich, dass sie in einer späteren Phase

oder gar nicht auftreten.

In der Initialisierung wird die Teamorganisation formalisiert aufgrund der Wahl des

methodischen Ansatzes (agil, klassisch oder hybrid). Zudem wird der Projektauftrag aus-

gehandelt. Damit ergeben sich folgende Maßnahmen.

Nach der Wahl der Methodik (agil, hybrid, klassisch) gilt es, die Schlüsselpositionen

im Team zu besetzen (agil: Abschn. 4.1.12.2 – klassisch: Abschn. 4.1.13.5).

Schlüsselpersonen auswählen: Die Auswahl des richtigen Projektleiters, Product Ow-

ners oder Scrum Masters ist für den Projekterfolg maßgebend.

Am System arbeiten (Abschn. 1.5.2): Mit dem ofﬁziellen Projektauftrag muss die Zu-

sammenarbeit im Team formalisiert werden.

Stakeholder managen (Abschn. 2.3.5): Unterschiedliche Sichtweisen und Erwartungen

der Stakeholder erfassen und deren Vernetzung bewirtschaften, beginnt in dieser Phase.

Bereits kleine Veränderungen sind in diesem Netzwerk spürbar.

Methodik

Teams aufstellen (Abschn. 4.1.9) sowie Rollen in der agilen (Abschn. 4.1.12) sowie

klassischen (Abschn. 4.1.13) Vorgehensweise bekleiden.

Dynamik in Teams berücksichtigen (Abschn. 4.2): Ein Projektteam kann schon in die-

ser ersten ofﬁziellen Projektphase aus dem „Forming“ in ein „Storming“ fallen. Damit

werden die Kompetenzen in persönlicher Kommunikation (Abschn. 3.9) sowie in Kon-

ﬂiktmanagement (Abschn. 4.4) gefordert.

Verhandlungen führen (Abschn. 4.3): Projektleiter sind in dieser Phase stark gefor-

dert, einen Projektauftrag mit den zuständigen Entscheidungsträgern auszuarbeiten, in

welchem die Einﬂussfaktoren des magischen Dreiecks (Abschn. 2.3.4) wie auch die

Verteilung von Auftrag/Aufgabe, Kompetenz und Verantwortung (Abschn. 4.1.5) in

einem realistischen Verhältnis zueinander stehen. Verhandlungsführung als wichtige

Kompetenz ist hier gefordert.

2.3.2

Zielsetzung

Ziele sind Aussagen darüber, was mit den zukünftigen Lösungen erreicht oder welcher zu-

künftige Zustand angestrebt werden soll. Sie sind Vorstellungen, Wünsche, Hoffnungen,

Emotionen zur Fragestellung: Was ist zu erreichen? Lösungen hingegen sind keine Ziele,

sondern Möglichkeiten, wie Ziele erreicht werden können.

Oft ist es zweckmäßig, zwischen Zielen und Anforderungen zu unterscheiden. Wäh-

rend Ziele aussagen, was mit der Lösung erreicht werden soll, beschreiben Anforderun-

gen, in welcher Qualität eine Lösung bzw. ein System sein soll, damit die Ziele erreicht

werden können. Anforderungen sind aus Zielen abgeleitet und im „Anforderungskatalog“

(etwa für Offerten) aufgelistet. Vielfach werden Ziele und Anforderungen als Synonym

verwendet: In diesem Fall ist zwischen Zielen und Detailzielen zu unterscheiden.

Die Bedeutung der Zielsetzung ist in der klassischen und in der agilen Vorgehenswei-

se unterschiedlich. Im klassischen Projektmanagement ist es wichtig, möglichst bald zu

einer präzisen, operationalisierten und stabilen Zielsetzung zu gelangen, welche den Maß-

stab zur Beurteilung der Lösungen bildet. Im agilen Bereich sind die Ziele (oft auch eher

Visionen) häuﬁg unscharf und Änderungen unterworfen, also ﬂexibel handhabbar. Das

„magische Dreieck“ in Abb. 2.5 zeigt die Unterschiede: Im klassischen Bereich sind die

Ziele von Anfang an genauer als die Kosten und Termine umschrieben und damit relativ

konstant, während im agilen Bereich Termine und Kosten möglichst rasch ﬁxiert sind und

sich die Ziele und Lösungsmöglichkeiten danach ausrichten (Abschn. 2.3.4).

Grundsätzlich bestimmt die Projektart, wie weit eine Zielstrukturierung getrieben wer-

den soll. So ist z. B. eine Zielstruktur in einem Organisationsprojekt weniger von Bedeu-

tung als in einem technischen und hochkomplizierten Anlageprojekt.

Im klassischen Projektmanagement können die Ziele anhand folgender Strukturie-

rungsmerkmale operationalisiert werden:

2.3

Phase Initialisierung

Scope (Vision, Ziele)

operationalisiert, rel. ﬁx

Zeit

Kosten

geschätzt,

eingeplant

geschätzt,

eingeplant

klassisch: Plan Driven

Scope (Vision, Ziele)

ungefähr, ﬂexibel

Zeit (Termine)

Kosten

ﬁx

agil: Vision Driven

Abb. 2.5 Magisches Dreieck im klassischen und agilen Projektmanagement

Globalziel und Detailziele

Systemziele und Vorgehensziele

Mussziele und Wunschziele

2.3.2.1

Zielsetzung entlang der Projektphasen

Der Zielsetzungsprozess entlang des Phasenverlaufs (siehe Tab. 2.5) ist im klassischen

und agilen Vorgehen ebenfalls unterschiedlich.

Im klassischen Projektmanagement, bei dem die Ziele relativ ﬁx sind und eine prägende

Orientierung für die Entwicklung der Lösungen bilden, ist es wichtig, die Zielsetzungen

und die Anforderungen möglichst frühzeitig zu formulieren und stufenweise zu verfei-

nern. Man ermöglicht sich damit eine breite Palette von Lösungsvarianten.

Im agilen Bereich, also wenn in Projekten mit neuen Erkenntnissen, angepassten Prio-

ritäten und Überraschungen zu rechnen ist, geht man iterativ, d. h. lernend vor. Dadurch

ﬂießen auch laufend neue Erkenntnisse bezüglich Zielen und Anforderungen ein. Der

Zielsetzungsprozess ist also über alle Phasen ﬂexibel. Am Anfang stehen eher ungefäh-

re Ziele (oder „Stories“ bzw. Visionen), die sich dann erst in der Realisierungsphase zu

Anforderungen konkretisieren.

Methodik

Tab. 2.5 Zielsetzung entlang der Projektphasen

Initialisierungsphase

Konzeptphase

Realisierungsphase

Agiles Projekt-

management

– Vision, ungefähres

Globalziel

– Produktkonzept

– Ziele und Anforderungen

– Aus „Stories“ des Kun-

den Anforderungen

(Produkt-Backlog) ab-

leiten

– Anforderungen entspre-

chend den Iterationen

– Laufendes Lernen prägt

die Anforderungen

(Produkt-Backlog)

Klassisches

Projektmanage-

ment

– Aus Analysen abge-

leitete Ziele

– Globalziel und

Anforderungen

(Lastenheft) for-

mulieren

– Zielsetzung laufend über-

prüfen und bei Bedarf

anpassen

– Kriterien für die

Beurteilung der Lösungs-

varianten ableiten

– Lösungskonzepte (Pﬂich-

tenheft) entwickeln

– Anforderungen

(Lastenheft) und

Lösungskonzepte

(Pﬂichtenheft) allen-

falls verfeinern oder

korrigieren

Der Zielformulierungsprozess zieht sich in vielen Projekten über mehrere Projekt-

phasen hin. Er zeichnet sich grundsätzlich dadurch aus, dass aus anfänglich vorliegen-

den Globalzielen (z. B. Einführung einer Titriersystem für die Analytica Messe bis Ende

April 2016) klare und speziﬁsche Anforderungen erarbeitet werden. Dabei werden die

Ziele durch iterative Anwendung des Problemlösungsprozesses stufenweise verfeinert.

Sie werden dadurch operationalisiert.

Auch Nichtziele sind hilfreich

Nichtziele können sehr nützlich sein, da sie das Projekt eingrenzen und den Freiraum für

neue Lösungen besser deﬁnieren. Oder umgekehrt: Ohne Formulierung von Nichtzielen

kann es passieren, dass neue Probleme oder Schwierigkeiten auftreten und zugelassen

werden. Auch können Nichtziele ein Hindernis für immer neue Wünsche sein, die unwei-

gerlich im Laufe des Projektprozesses auftreten. Beispiele:

Mit der neuen Regelung darf keine zusätzliche Bürokratie entstehen!

Die Anpassung der Website erfolgt ohne Neuformulierung der Texte (dieses Nichtziel

kann auch als Rahmenbedingung bezeichnet werden)

2.3.2.2

Globalziel und Detailziele

Das Grob- oder Globalziel ist oft Bestandteil des Projektauftrags und kommt kurz und

prägnant daher. Es charakterisiert den zu erreichenden Endzustand im Projekt schwer-

punktmäßig und dient den Projektmitarbeitern zur Orientierung. Die Formulierung des

Globalziels beinhaltet eine prägnante Aussage bezüglich:

Was soll erreicht werden?

Qualität, Funktionalität, Umfang

Wann soll das erreicht werden?

Zeitliche Begrenzung

Womit soll das erreicht werden?

Kostenrahmen

2.3

Phase Initialisierung

Beispiel

Praxisbeispiel BLS Projekt Vertriebs-Back-End

Globalziel: Technologisches Fundament für eine erweiterbare, zukunftsorientierte, un-

abhängige und mandantenfähige Vertriebsplattform der BLS, mobile Lösung (App),

online Ticketshop und Fahrplanlösung für das Projekt bls.ch bis zum Fahrplanwechsel

Dezember 2016 innerhalb des deﬁnierten Budgets.

Beispiel

Praxisbeispiel Projekt Metrohm OMNIS Titriersystem

Globalziel, welches zu Beginn des Projektes im Jahr 2012 deﬁniert wurde: Um die

Marktführerschaft im Gebiet der Titration weiter zu stärken soll ein „best in class“

Titrations-System auf den Markt gebracht werden.

Es soll ein vollautomatisiertes, modulares, anwenderfreundliches Titrationssystem

mit führender Messpräzision entwickelt werden, mit dem Ziel, im Jahr 2016 ein Mi-

nimal Viable Product (MVP) für die potentiometrische Titration anbieten zu können,

welches in den folgenden Jahren mit weiteren Titrationsmethoden erweitert wird. Das

System soll aus einer Robotik Lösung für das Probenhandling, einem Bearbeitungs-

modul, einem Messmodul sowie einer neuen Softwareplattform bestehen. Nichtziele

vom MVP für 2016: es sollen keine Geräte vom aktuellen Portfolio in die Software im

System eingebunden werden. Der geplante Kostenrahmen soll eingehalten werden und

wird quartalsweise überprüft.

Detailziele werden als Anforderungen formuliert. Diese können in umfangreichen

und komplexen Projekten bis zu mehrere hundert Seiten umfassen und werden in vielen

Branchen in ihrer Gesamtheit auch als Speziﬁkation, Lastenheft, Anforderungskatalog

oder nicht ganz korrekt als Pﬂichtenheft bezeichnet.

2.3.2.3

Systemziele und Vorgehensziele

Systemziele sind alle Forderungen und Bedürfnisse, welche am Ende des Projektes mit

der Lösung zufriedengestellt werden sollen. Sie sind die Beurteilungskriterien für die Pro-

jektlösung: Leistungs- und Qualitätsziele, Terminziel, wirtschaftliche Ziele. Darunter sind

auch sämtliche Vorstellungen des Auftraggebers hinsichtlich der kurz- und langfristigen

Wirkungen und des Nutzens zu verstehen, die das Projekt erzielen soll.

Vorgehensziele umfassen alle Vorgaben oder Auﬂagen, welche während des Projekt-

ablaufes zu erfüllen, am Ende des Projektes aber nicht mehr relevant sind. Vorgehenszie-

le können Meilensteine festlegen, bestimmte Hilfsmittel für die Durchführung vorgeben

oder/und Auﬂagen zur Vermeidung von Störungen durch den Projektablauf machen. Sie

bilden häuﬁg Rahmenbedingungen in der Abwicklung eines Projektes.

Das Praxisbeispiel der BLS zeigt in Tab. 2.6 Systemziele und Vorgehensziele.

Methodik

Tab. 2.6 Praxisbeispiel BLS: „Vorgehens- und Systemziele“

Systemziel

Vorgehensziel

– Anbindung an die öV-Plattform via NOVA-

Schnittstelle

– Mandantenfähigkeit bezüglich Vertriebs-Back-

End und digitale Verkaufskanäle

– ausbaufähige Architektur, welche den Anschluss

aller Vertriebskanäle erlaubt

– Realisierung einer mobilen Lösung für den

Ticketverkauf

– Realisierung des online Ticketshops für bls.ch

– Integration eines Fahrplans in die mobile Lö-

sung und den Online-Ticketshop

– Das Projekt wird nach der Vorgehens-

methodik HERMES 5.1 abgewickelt

und durchläuft die BLS-internen Quali-

ty Gates (systematische Überprüfung der

Zwischenergebnisse zu deﬁnierten Mei-

lensteinen).

– Laufende Abstimmung mit Postauto und

Südostbahn bezüglich der NOVA-Anbin-

dung.

2.3.2.4

Kriterien für zweckmäßige Projektziele

Beim Formulieren von Projektzielen sind folgende Regeln zu beachten:

Ziele so beschreiben, als ob sie bereits erreicht wären; dies hat eine suggestive Wir-

kung. Beispielsweise so: „Ein halbes Jahr nach Inbetriebnahme der Lösung sind die

gesamten Projektkosten amortisiert“.

Ziele lösungsneutral formulieren: Was kann wahrgenommen werden, wenn das Ziel

erreicht ist? Werden Lösungen vorgegeben oder beschrieben, besteht die Gefahr, dass

gute Lösungen zu früh ausgeschlossen werden. Beispiel: „Bei Anruf eines Kunden

stehen die aktuellen Informationen über ihn zur Verfügung.“ Und nicht: „System XY

liefert aktuelle Kundendaten auf den Bildschirm.“

Neben den Zielen sind auch die Rahmenbedingungen festzuhalten: Was muss einge-

halten werden? Was darf unter keinen Umständen passieren? z. B. welche Sicherheits-

aspekte müssen respektiert werden?

Ziele möglichst operational formulieren: Einfach, verständlich, klar, eindeutig messbar

oder so, dass die Zielerreichung beurteilt werden kann. Insbesondere sollen quantita-

tive Ziele in absoluten Werten angegeben werden und nicht lediglich als prozentuale

Verbesserung (gegenüber einer oft nicht genannten Referenzgröße). Zum Beispiel „Die

Ausschussquote soll von heute 1 auf maximal 0,75% reduziert werden“ anstatt „Hal-

bierung der Ausschussquote“ oder „Reduktion der Ausschussquote um 50 %“

Ziele sollen realistisch sein, auch wenn die Lösung im Moment noch nicht ersichtlich

ist. Realistisch meint, dass die Zielerreichung von den Beteiligten aktiv beeinﬂusst wer-

den kann. Ziele dürfen dabei anspruchsvoll, herausfordernd sein, weil dies vor allem in

einem innovativen Umfeld stark motivierend wirkt.

Operationelle Detailziele sollen in der klassischen Vorgehensweise so früh wie mög-

lich nach dem Projektauftrag und so präzise wie möglich formuliert, später im Projekt-

ablauf allenfalls geändert oder ergänzt werden.

Ziele können auch priorisiert bzw. gewichtet werden: welche Ziele sind wichtiger als

andere?

2.3

Phase Initialisierung

Zusammenfassend ist die Formel SMART hilfreich:

SMARTe Ziele sind:

Spezifisch

Messbar

Attraktiv/Anspruchsvoll

Realistisch

Terminiert

Im englischen Sprachgebrauch werden teilweise auch die Begriffe Achievable und

Relevant genutzt.

In vielen Situationen sind die Nutzenziele bei Abschluss des Projekts noch gar nicht

messbar, z. B. bei Organisationsentwicklungsprojekten, welche Efﬁzienzsteigerungen

oder kulturelle Verbesserungen erreichen möchten. In solchen Situationen gilt es, geeig-

nete messbare Indikatoren für die eigentliche Zielerreichung zu identiﬁzieren. Beispiele:

Fehlerrate von 10 auf 5 % senken, Durchlaufzeit von heute zwölf auf zehn Monate re-

duzieren, Reduktion der Anzahl Schnittstellen von 50 auf 40, Personalﬂuktuation um

3 Prozentpunkte von 11,5 auf 8,5 % reduzieren, Anzahl Lagerteile auf 1500 Stück hal-

bieren, Gewinnmarge um 33 % von aktuell 12 % auf 16 % erhöhen. Diese Indikatoren

können dann ein halbes oder ganzes Jahr nach Projektabschluss überprüft werden.

Ziele gemeinsam ﬁnden und vereinbaren

Ziele müssen diskutiert, hinterfragt und vor allem akzeptiert sein. Deshalb wird der Pro-

jektleiter oder der Product Owner die Projektziele nie allein formulieren, sondern mit dem

Auftraggeber, dem Projektteam, allenfalls mit dem Projektausschuss oder mit einem Be-

gleitteam erarbeiten und abstimmen. Ziele müssen mit allen Projektinvolvierten vereinbart

werden, alle müssen sich dafür verantwortlich fühlen.

2.3.2.5

Mussziele und Wunschziele

Oft ist es auch sinnvoll, zwischen zwingend zu erreichenden und möglichst zu erreichen-

den Zielen zu unterscheiden:

Mussziele oder Ausscheidekriterien

Wunschziele oder Optimierungskriterien

Mussziele, bzw. Ausscheidekriterien sind Bedingungen, die zwingend zu erreichen

oder einzuhalten sind, damit eine Lösung sinnvoll oder brauchbar ist, selbst wenn es mehr

kostet oder länger dauert. Dazu gehören vor allem Gesetze, Sicherheitsvorschriften, Nor-

men usw. Die Lösungen, welche die Muss-Ziele nicht erreichen, werden ausgeschieden,

nicht akzeptiert. Mussziele müssen widerspruchsfrei sein.

Wunschziele bzw. Optimierungskriterien sind Ziele ohne Ausscheidecharakter. Da

diese mehr oder weniger starke Wünsche sein können und außerdem oft gegenläuﬁg sind

Methodik

(mit Widersprüchen behaftet), wie z. B. Kostenziele einerseits und Kosten verursachende

Leistungs- und Qualitätsziele andererseits, müssen Optimierungskriterien immer mit einer

zusätzlichen Angabe versehen werden: der Gewichtung. Die Gewichtung ist am einfachs-

ten verständlich, wenn sie in % ausgedrückt wird.

2.3.3

Anforderungen/Requirements Engineering

Anforderungen leiten sich aus den Zielsetzungen ab. Sie konkretisieren die Zielsetzung

und beantworten die Frage „Was soll erreicht werden?“. Die Anforderungen sind viel

konkreter und detaillierter formuliert als die Zielsetzung. Die Anforderungen werden in

einem Lastenheft zusammengefasst. Die weitere Konkretisierung der Anforderungen zu

einem Lösungskonzept beantwortet die Frage „Wie soll die Anforderung umgesetzt wer-

den?“. Dieser Schritt wird im Pﬂichtenheft dargestellt. Abb. 2.6 zeigt den Zusammenhang

zwischen Zielen, Anforderungen und Lösungskonzept.

In der klassischen Vorgehensweise sollen die Anforderungen alle Kriterien beinhal-

ten, nach welchen später eine Lösung oder Lösungsvariante beurteilt und bewertet wird.

Checklisten helfen schon früh im Projekt, Vollständigkeit zu erreichen. Wird bezüglich

Globalziel

Detailziele

Funktionalität

Qualität

Rahmenbedingungen

Anforderung hinsichtlich…

(Lastenheft, was soll erreicht werden?)

Lösungskonzept

(Pﬂichtenheft, wie sollen Anforderungen umgesetzt werden?)

Abb. 2.6 Zusammenspiel zwischen Zielen, Anforderungen und Lösungskonzept

2.3

Phase Initialisierung

eines Lösungsaspektes keine Anforderung formuliert, so fehlen die Kriterien zur Auswahl

der besten Lösung.

Umfassend werden Lastenheft und Pﬂichtenheft primär in der klassischen Vorge-

hensweise ausgearbeitet.

In der agilen Vorgehensweise werden die Anforderungen iterativ in der Realisierungs-

phase erarbeitet. Weiter ist eine scharfe Trennung des Lasten- und Pﬂichtenhefts nicht

immer möglich. Die Anforderungen werden in einem Product Backlog (Abschn. 2.4.3)

geführt.

Anforderungen (Requirements) werden nach IEEE 610.12-1990 wie folgt deﬁniert:

Eine Bedingung oder Fähigkeit, die von einem Benutzer (Person oder System) zur

Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird.

Eine Bedingung oder Fähigkeit, die ein System oder Teilsystem erfüllt oder besitzt,

muss einen Vertrag, eine Norm, eine Speziﬁkation oder andere formell vorgegebene

Dokumente erfüllen, um ein Ziel zu erreichen.

2.3.3.1

Tätigkeiten des Requirements Engineering

Anforderungen werden im Requirements Engineering – oft als RE abgekürzt – erarbeitet

und deﬁniert. Die Haupttätigkeiten des Requirements Engineering lassen sich wie folgt

zusammenfassen:

Ermitteln: Anforderungen gewinnen, detaillieren und verfeinern

Dokumentieren: Anforderungen adäquat beschreiben

Prüfen und Abstimmen: Qualitätskriterien prüfen

Verwalten: Requirements Management

Eine weitere wichtige Aufgabe des Requirements Engineering ist es Kontext, System-

grenzen und Lieferumfang (Scope) zu klären.

Anforderungen werden durch die Anwendung unterschiedlicher Erhebungstechniken

ermittelt, wie beispielsweise durch Befragung (Interview, Fragebogen), Einsatz von Krea-

tivitätstechniken (Brainstorming, Wechsel der Perspektive) oder Beobachtung (Feldbeob-

achtung, Arbeit des Anwenders unter seiner Anleitung verrichten).

2.3.3.2

Arten von Anforderungen

Tab. 2.7 zeigt die drei Arten von Anforderungen.

Die Rahmenbedingungen (auch als Randbedingungen bezeichnet) sind keine Anfor-

derungen, die umgesetzt werden, sie schränken den Lösungsraum jedoch ein. Es gilt

Gesetze (beispielsweise Rechtsvorschriften, Vorschriften für Sicherheit, Gesundheit und

Umweltschutz), Normen und Standards (beispielsweise relevante Verhaltensregeln, Be-

rufsvorschriften, Prinzipien und Ziele der Nachhaltigkeit) zu identiﬁzieren und dafür zu

sorgen, dass diese eingehalten werden.

Methodik

Tab. 2.7 Arten von Anforderungen

Funktionale Anforderungen

Nicht-Funktionale Anforderungen

– Funktionen/Fähigkeit des

Systems

– Verhaltensanforderungen

– Strukturanforderungen

– Geschäftsregeln

– Daten

– Zustände

– Fehlerbehandlung

– Schnittstellen

Qualitätsanforderungen:

– Details zu Funktionen (Si-

cherheit, Genauigkeit)

– Zuverlässigkeit

– Benutzbarkeit

– Efﬁzienz

– Änderbarkeit

– Übertragbarkeit

Rahmenbedingungen (organi-

satorisch und technisch):

– Entwicklungsprozess

– Budget

– Termine

– Team

– Gesetze

– Normen

– Standards

– Betrieb

Tab. 2.8 Kriterien für die Güte von Anforderungen und Anforderungsdokumenten

Anforderungen

Anforderungsdokument

– Abgestimmt

– Bewertet

– Eindeutig

– Gültig und aktuell

– Korrekt

– Konsistent

– Prüfbar

– Realisierbar

– Verfolgbar

– Vollständig

– Verständlich

– Konsistent

– Eindeutig/Versioniert

– Klar strukturiert

– Modiﬁzierbar

– Erweiterbar

– Vollständig

– Verfolgbar

2.3.3.3

Kriterien für die Güte von Anforderungen und

Anforderungsdokumenten

Anforderungen und Anforderungsdokumente können anhand der Kriterien in Tab. 2.8 auf

ihre Güte überprüft werden.

2.3.3.4

Priorisierung von Anforderungen

In vielen Projekten formulieren die Anwender, Kunden oder das Marketing mehr Anfor-

derungen und Wünsche als in nützlicher Frist oder mit den zur Verfügung stehenden Mittel

umgesetzt werden können. Damit die wichtigen und zentralen Anforderungen umgesetzt

werden, müssen diese priorisiert werden. Im Projektverlauf können sich Anforderungen

und Wünsche auch verändern. Die agile Vorgehensweise nimmt diesen Umstand auf. Bei

Scrum werden die Anforderungen im Product Backlog laufend priorisiert. Eine Priorisie-

rung der Anforderungen hilft dem Projektteam den Fokus auf die wichtigen und zentralen

Anforderungen zu legen.

Das Priorisieren von Anforderungen ist anspruchsvoll und geschieht durch die Vertreter

der Anwender, Kunden oder das Marketing. Bei Scrum fällt diese Aufgabe dem Product

Owner zu.

2.3

Phase Initialisierung

Grad der Kundenzufriedenheit

Erfüllungsgrad der Forderungen

enttäuscht

begeistert

schlecht

gut

intelligente

Schaltung

Begeisterungs-

merkmale

Basis/Grund-

anforderungen

Leistungs-

anforderungen

unausgesprochen

ausgesprochen

Anzahl der

Gänge

Zeit

Indifferenz-

zone

funktionssichere

Bremse

Abb. 2.7 Kano Modell zur Bestimmung von Nutzen

Häuﬁg verwendete Kriterien für die Priorisierung sind Nutzen, Kosten und Risiko.

Für die Durchführung der Priorisierung stehen verschiedene Methoden zur Verfügung.

Es empﬁehlt sich, verschiedene Methoden miteinander zu kombinieren.

Kano-Modell zur Bestimmung von Nutzen

Kano unterscheidet in seinem Modell zwischen Basis-, Leistungs- und Begeisterungsan-

forderungen, siehe Abb. 2.7. Die Erfüllung der Basisanforderungen (z. B. beheizte Fe-

rienwohnung im Winter, auch bei Regenwetter funktionierende Bremse beim Fahrrad)

ist essentiell, führt jedoch zu keiner hohen Kundenzufriedenheit. Leistungsanforderungen

(z. B. Anzahl Zimmer, Ausstattung der Küche in der Ferienwohnung, Anzahl der Gänge

des Fahrrads) führen zu einem linearen Anstieg der Kundenzufriedenheit. Bei den Leis-

tungsanforderungen gilt das Motto „Je mehr, desto besser“. Begeisterungsmerkmale (z. B.

schöne Aussicht, gute Lage, intelligente Schaltung) führen zu einer hohen Kundenzufrie-

denheit. Die Indifferenzzone ist der Bereich, in dem die Erwartungen mehr oder weniger

erfüllt werden. Die Zufriedenheitswerte in dieser Zone verhalten sich moderat. Außer-

halb der Indifferenzzone steigen, bzw. sinken die Zufriedenheitswerte der Basis- und

Begeisterungsanforderungen überproportional. Es gilt in der Priorisierung eine geschickte

Kombination der Anforderungskategorien zu ﬁnden, wobei die Basisanforderungen zwin-

Methodik

gend umzusetzen sind. Im Zeitverlauf verschieben sich Begeisterungsanforderungen zu

Leistungsanforderungen und Leistungsanforderungen zu Basisanforderungen.

MoSCoW-Priorisierung

Die MoSCoW Priorisierung (teilweise auch unter der Schreibweise MuSCoW geläuﬁg)

unterteilt die Anforderungen in vier Gruppen: Must have, Should have, Could have und

Won’t have:

MUST: Die Umsetzung ist für die Abnahme zwingend erforderlich.

SHOULD: Anforderungen müssen ebenfalls umgesetzt werden, sind aber im Gegen-

satz zu den MUST-Anforderungen durch Change Requests oder Verhandlungen verän-

derbar.

COULD: Diese Anforderungen werden umgesetzt, wenn alle Must- und Should-Anfor-

derungen erfüllt sind und noch ausreichend Ressourcen und Zeit zur Verfügung stehen.

WON’T: Diese Anforderungen werden im aktuellen Projekt noch nicht umgesetzt und

stattdessen in einem Ideenpool oder der Anforderungsliste für das nächste Projekt ge-

speichert.

Businesswert

Wie im Abschn. 2.4.6 Aufwandschätzung beschrieben, werden für die einzelnen Anforde-

rungen die Businesswerte mittels der T-Shirt-Sizing-Methode bestimmt. Die Anforderun-

gen mit den höchsten Businesswerten bekommen die höchste Priorität für die Umsetzung.

Kosten

Eine reine Priorisierung anhand der geschätzten Kosten macht meistens wenig Sinn. Die

Gegenüberstellung von Businesswert und Kosten kann wertvollen Input für die Priori-

sierung liefern. Siehe dazu auch Abschn. 2.4.6.3 Aufwandschätzung mit T-Shirt Sizing

Methode.

Bei dieser Methode werden die Anforderungen nach Wert (Nutzen) und Risiko geord-

net. Die Reihenfolge der Umsetzung der Anforderungen ergibt sich aus Abb. 2.8. Durch

die prioritäre Umsetzung von Anforderungen mit einem hohen Nutzen und hohen Risiken

werden die relevanten Pain Points am Anfang im Projekt adressiert. Dies hilft dem Pro-

jektteam, sich am Anfang mit den schwierigen Herausforderungen auseinanderzusetzen

und diese nicht auf die lange Bank, beziehungsweise auf der Zeitachse hinauszuschieben.

Umgang mit Änderungen

Im Verlaufe des Projektes können Änderungen entstehen durch:

Kundenwünsche, Kundenbeanstandungen

Neue Erkenntnisse

Entwicklungsfehler

nicht mehr lieferbare Komponenten oder Materialien

2.3

Phase Initialisierung

hoch

gering

Risiko

Wert

als Erstes umsetzen

vermeiden

zuletzt umsetzen

als Zweites umsetzen

Abb. 2.8 Wert-Risiko-Matrix

geänderte Vorschriften

allgemeine Produktverbesserungen

Verbesserung der Wirtschaftlichkeit

In der klassischen Vorgehensweise ist es vorteilhaft, wenn bereits zu Beginn des Pro-

jektes vereinbart wird, wie mit Änderungen verfahren wird. Zwischen den Beteiligten ist

die Abgrenzung zwischen initialer Ziel- und Anforderungsdeﬁnition und Change Request

zu klären: Bis wann können präzisierende Änderungen an Zielen und Anforderungen oh-

ne Kostenfolge vorgenommen werden bzw. ab wann ist der Änderungsprozess (Change

Request) anzuwenden?

Das Thema Änderungsmanagement wird in Abschn. 2.5.8 ausführlich behandelt.

In der agilen Vorgehensweise sind Änderungen willkommen. Änderungen werden in

den Product Backlog aufgenommen und zusammen mit den anderen Anforderungen lau-

fend priorisiert.

Methodik

Zu Beginn des Projekts

Gegen Ende des Projekts

Während des Projekts

Zeit

Kosten

Scope

Abb. 2.9 Das magische Dreieck

2.3.4

Das magische Dreieck

Das „magische Dreieck“ wird im Projektmanagement dazu verwendet, die gegenseitige

Abhängigkeit der Einﬂussfaktoren „Scope“ (Vision, Ziele), „Kosten“ und „Zeit“ darzu-

stellen, siehe Abb. 2.9.

Scope: Gewünschte Ergebnisse aus dem Projekt: Umfang, Qualität, Funktionalität,

Komfort, Service Levels etc.

Zeit: Gewünschter Zeitraum für die Erreichung der vereinbarten Projektziele

Kosten: Kosten inkl. Arbeitsleistung und andere Ressourcen, die maximal dafür ein-

gesetzt werden können

Keiner dieser Faktoren kann verändert werden, ohne dass dies einen Einﬂuss auf die

beiden anderen Faktoren hätte. Es sind dies die drei entscheidenden Verhandlungsgrößen,

welche mit dem Auftraggeber bzw. Kunden möglichst detailliert formuliert und verab-

schiedet werden müssen. Der Projektleiter muss vom Auftraggeber verlangen, diese drei

Dimensionen zu gewichten. Damit ist sein Handlungsspielraum für den Umgang mit

diesen drei Grenzen abgesteckt. Dies mag der „magische Anteil“ sein: Wie geht der Pro-

2.3

Phase Initialisierung

Tab. 2.9 Unterschiedliche Projekt-Strategien mit Einﬂuss auf die Projektziele

Best-in-Market

Höchste Priorität hat die Maximierung von Qualität bzw. Funktionalität.

Durch diese „Attraktion“ sollen am Markt möglichst viele neue Kunden an-

gesprochen werden.

Time-to-Market

Höchste Priorität hat eine minimale Projektdauer, um so rasch wie möglich

am Markt auftreten zu können (z. B. Produktentwicklung). Kosten und Quali-

tät sind von eher untergeordneter Bedeutung.

Design-to-Cost

Höchste Priorität hat das Kostenziel, d. h. wie viel das erarbeitete Resultat

kosten darf. Der Projektleiter bricht das Kostenziel herunter auf kleinere

Einheiten und überwacht diese Teilkostenziele (auch „target costing“).

jektleiter mit diesen gegenläuﬁgen Anforderungen um? Über diesen Balanceakt hinaus

hat der Begriff nichts mit Magie zu tun. Im Gegensatz zum Englischen, wo der Begriff

„Tripple constraint“ diese drei Restriktionen gut beschreibt, fehlt im Deutschen ein pas-

sender Begriff.

Manchmal wird auch den Verbindungslinien im magischen Dreieck eine Bedeutung

zugeordnet: Zwischen Scope und Kosten steht die Rentabilität, zwischen Scope und Zeit

die Effektivität und zwischen Kosten und Zeit die Produktivität. Verschiedene Strategien

führen zu unterschiedlicher Gewichtung, siehe Tab. 2.9.

Wie in Abschn. 2.3.2 aufgezeigt, gibt es im magischen Dreieck auch Unterschiede

zwischen der agilen und der klassischen Vorgehensweise. Bei der agilen Vorgehensweise

sind Zeit, Kosten und Teamgröße ﬁx. Hingegen ist bei der klassischen Vorgehensweise

der Scope ﬁx.

Die Bedeutung der Ecken des magischen Dreiecks verändern sich auch im Verlauf

eines Projektes. Zuerst liegt der Fokus auf der Findung und der Deﬁnition des Scopes,

schon bald wechselt der Fokus auf die Kosten und gegen Schluss des Projektes liegt der

Fokus auf der Zeit.

2.3.5

Stakeholder-Management

2.3.5.1

Anspruchsgruppen managen

Anspruchsgruppen oder Stakeholder sind Personen, Gruppen oder Organisationen, die

zum Projekt relevante Beziehungen haben. Diese Beziehungen können sein: Betroffen-

heit, bestimmte Interessen, Legitimation oder auch Erfahrungen. Unternehmensexterne

Anspruchsgruppen werden manchmal als unsichtbares Projektteam bezeichnet, da sie das

Projekt wesentlich beeinﬂussen, unterstützen oder sogar zu Fall bringen können. So stellen

unterschiedliche Anspruchsgruppen oft auch widersprüchliche Forderungen an ein Pro-

jekt.

Einﬂussreiche Stakeholder versuchen beispielsweise, den Zielsetzungen und der Pro-

jektplanung ihren Stempel aufzudrücken und gewisse Teilergebnisse früher zu verlangen

Methodik

als geplant. Oder Investoren haben ein Interesse, die Projektrisiken niedrig zu halten. Die-

se Einﬂussnahme kann auf einer formellen oder informellen Ebene erfolgen.

Bildlich gesprochen ist das Projekt in ein soziales Netz oder Kräftefeld eingebunden,

das es nicht nur zu berücksichtigen gilt, sondern das für den Projekterfolg nutzbar ge-

macht werden soll. Mit den Anspruchsgruppen kann unterschiedlich verfahren werden:

es können kommunikative Beziehungen aufgebaut werden, sie können aber auch in die

Projektorganisation einbezogen werden. Bei sehr unterschiedlichen Interessen ist es oft

vorteilhaft, Möglichkeiten zu schaffen, dass Vertreter von Anspruchsgruppen gegenseitige

Interessen und Meinungsverschiedenheiten direkt ausdiskutieren können. Damit besteht

eher die Gewähr, dass eine breit abgestützte und somit solide Lösung entstehen kann

(Abschn. 1.6.3).

Eine Stakeholder-Analyse wird mit Vorteil bereits möglichst am Anfang des Projek-

tes mit dem Auftraggeber und dem Projektteam erarbeitet. Damit entstehen auch eine

gemeinsame „Projektwirklichkeit“ und ein Gespür für die Vernetzung des Projektes. Die

Stakeholder-Analyse soll während der gesamten Projektdauer regelmäßig aktualisiert wer-

den. Das Stakeholder-Management umfasst vier Schritte:

1. Stakeholder identiﬁzieren

2. Stakeholder analysieren

3. Stakeholder bewerten

4. Stakeholder steuern

2.3.5.2

Stakeholder identifizieren

Wer stellt besonders wichtige Ressourcen bereit?

Wer kann Einﬂuss nehmen auf das Projekt?

Wer ist vom Projekt besonders betroffen?

Wer kann den Projekterfolg fördern oder hemmen?

Wer braucht die Projektergebnisse?

Wer darf nicht übergangen werden?

2.3.5.3

Stakeholder analysieren

Bildhafter Aufbau der Stakeholder: Stakeholder um das Projekt gruppieren

Intensität und Qualität des Einﬂusses und des Interesses der einzelnen Stakeholder

benennen und visualisieren, z. B. Nähe zum Projekt durch Positionierung nahe vom

Projekt und Qualität der Beziehungen mit Symbolen für positiv, neutral oder negativ,

wie in Abb. 2.10 aufgezeigt.

2.3.5.4

Stakeholder bewerten

Für jeden Stakeholder sind sein Interesse und sein Einﬂuss und seine Macht (Abschn. 4.1.3)

auf das Projekt abzuschätzen. Die Einﬂussnahme kann auf einer formellen oder informel-

len Ebene erfolgen. Es interessiert auch die Frage wie der Stakeholder auf das Projekt

2.3

Phase Initialisierung

Erwartete Reaktion:

positiv, fördernd

neutral, indifferent

negativ, hindernd

Projekt

Mitbewerber

Mitarbeiter

Lieferanten

Auftraggeber

Behörden

Kunden

Projektleiter

Abb. 2.10 Das Projekt als soziales System ist mit unterschiedlichen Anspruchsgruppen vernetzt

reagieren wird. Diese Aufgabe wird am einfachsten in Tabellenform dargestellt, siehe da-

zu Tab. 2.10.

Zur Bearbeitung dieser Fragstellung sind folgende Überlegungen hilfreich:

Was denken die Stakeholder über das Projekt? Das Problem soll aus den verschiedenen

Perspektiven der Anspruchsgruppen betrachtet werden.

Wie sind die Beziehungen der Stakeholder zueinander? Wie stehen sie zueinander?

Welche Interessen und Ziele verfolgen die einzelnen Stakeholder? Wo gibt es allenfalls

Ziel- und Interessenkonﬂikte (Abschn. 4.4.7.1)?

Mit welchen Reaktionen und Verhaltensweisen der Stakeholder muss der Projektleiter

oder Product Owner rechnen?

Aus der ersten Analyse lässt sich eine Stakeholder-Landkarte ableiten, siehe Abb. 2.11.

2.3.5.5

Stakeholder steuern

Anhand der Analyse und Bewertung der Stakeholder werden Maßnahmen formuliert und

umgesetzt.

Methodik

Tab. 2.10 Praxisbeispiel BLS: Auszug tabellarische Darstellung einer Stakeholder-Analyse

Stakeholder

Interesse

Macht,

Einﬂuss,

Legitimation

Erwartete Re-

aktion auf das

Projekt

Maßnahmen

Auftraggeber Betroffenheit

Trifft re-

levante

Projektent-

scheide

zusammen

mit Projekt-

steuerungs-

ausschuss

Zustimmung

Laufende Ab-

stimmung

Trident Pro-

jekte

Erfolgreiches

Projekt, ter-

mingerechte

Einführung

Keinen direk-

ten Einﬂuss

auf das Pro-

jekt

Zustimmung,

evtl. Konkur-

renzkampf um

Ressourcen

Laufende Ab-

stimmung,

Erstellung ge-

meinsamer

Planung für die

Abhängigkeiten

Kunde

Gegenseitige

Projektab-

hängigkeiten,

teilweise Zu-

griff auf die

gleichen Res-

sourcen

Nutzung be-

ziehungsweise

Nicht-Nut-

zung des

neuen An-

gebots

Abwarten und

neue mobile

Ticketlösung

(App) prüfen

Werbung und

PR machen

Allgemeine

Öffentlich-

keit

Großes Interes-

se, wenn neue

mobile Ticket-

lösung (App)

Vorteile bringt

Kein direkter

Einﬂuss auf

das Projekt

Negative Reak-

tion möglich,

warum braucht

es neben der

SBB noch wei-

tere mobile

Ticketlösungen?

Werbung und

PR machen

Grad der Beziehung zum Projekt: 3 = hoch, 2 = mittel, 1 = klein

Art der Beziehung: + = positiv, = negativ, ? = unbekannt, Ø = neutral

Mögliche Ansätze für den Umgang mit Stakeholdern sind:

Stakeholder im Projekt einbinden, d. h. sie in ein geeignetes Projektgremium aufneh-

men sowie Aufgaben und Rollen der Anspruchsgruppen im Projekt deﬁnieren

Interessen und Zielsetzungen klären, Ziel- oder Interessenkonﬂikte mit Konﬂiktma-

nagement oder Mediation bereinigen

Basierend auf dem Informations- und Kommunikationskonzept Stakeholder adressa-

tengerecht informieren und den Dialog pﬂegen, d. h. die Kommunikationsarten und

-kanäle bewusst auf die Stakeholder ausrichten.

Zusätzliche Kommunikationsgefäße schaffen, z. B. Workshop/Großgruppeninterven-

tion/Informationsveranstaltung.

2.3

Phase Initialisierung

Intern

• Abteilung FR (+)

Intern

• Abteilungen UK,

UR, PM, PV, T, FCP,

FE (?)

Extern

• Kunde (?)

Intern

• Projektsteuerungs-

ausschuss (+)

• Auftraggeber (+)

Intern

• Mitarbeitende,

Geschäftsleitung (+)

• Trident-Projekt (+)

• Innovations-

projekte (?)

• Verwaltungsrat (+)

Extern

• Presse

Intern

• Abteilung UE (+)

Extern

• BAV (+)

• AöV (?)

Extern

• Öffentlichkeit (-)

• ÖV-Branche,

Projekt ZPS (?)

Intern

• Andere Bereiche

P und T (?)

Einﬂuss

Interesse

Abb. 2.11 Praxisbeispiel BLS: Stakeholder Landkarte

Damit der Projektleiter oder Product Owner erfolgreich die Stakeholder steuern kann,

muss er von der Linie ermächtigt sein, seine Rolle zu spielen. Der Product Owner oder

Projektleiter muss die Stakeholder auf allen drei Ebenen der Zusammenarbeit (Beziehung,

Inhalt und Organisation) ansprechen (Abschn. 1.5) und in das Projekt involvieren.

Die Stakeholder-Landkarte (Abb. 2.12) zeigt direkt auf, wie die Projektverantwortli-

chen mit wem umgehen sollen.

Macht und Einﬂussnahme der Stakeholder sind kaum steuerbar. Steuerbar ist aber die

Beziehung der Stakeholder zum Projekt durch Beziehungsmanagement

Veränderungen und Entwicklungen in Bezug auf die Stakeholder feststellen

Regelmäßig mit den Stakeholdern kommunizieren

Die getroffenen Maßnahmen periodisch kontrollieren und anpassen

2.3.6

Projektmarketing

Das Projektmarketing umfasst alle unterstützenden Aktivitäten, welche die Akzeptanz so-

wie den Verlauf und den Fortschritt eines Projektes positiv beeinﬂussen können. Es geht

darum, das Projekt zu verkaufen, wobei unter „verkaufen“ verstanden wird:

Methodik

gross

klein

gering

mittel

Einﬂuss

Interesse

Minimal Kontakt

halten,

beobachten,

Interesse zeigen

Gut informieren,

Anliegen ernst

nehmen

Grösste

Aufmerksam-

keit schenken,

einbinden,

eng zusammen-

arbeiten

Informieren

und Kontakt

halten

Abb. 2.12 Strategien im Umgang mit Anspruchsgruppen

Den Sinn des Projektes kommunizieren, Nutzen stiften, die eigene Überzeugung wei-

tergeben

Vertrauen und Akzeptanz schaffen

Fairness zeigen: auch mögliche Nachteile oder Probleme transparent machen, Ängste

und Fragen ernst nehmen und behandeln

Öffentlichkeit herstellen, Erwartungen erzeugen, die dem Projekt Energie geben

Ressourcen und Absatzmärkte erschließen

Das Projektmarketing fördert die Beziehungen zwischen Projekt und Umfeld bzw. sei-

nen Anspruchsgruppen (Stakeholdern).

Projektmarketing bedeutet Kommunikationsgestaltung und kann je nach Situation und

Anspruchsgruppen sehr kreativ angegangen werden, z. B.:

Breite Information mit Möglichkeit zur Auseinandersetzung mit dem Thema (z. B.

Open Space Event)

Projekt Blog, in dem sich auch Betroffene, Benutzer, also nicht Projektakteure kritisch

äußern dürfen

2.3

Phase Initialisierung

Info-Markt: Informationstafeln und Stände mit Unterlagen; Projektbeteiligte stehen

Rede und Antwort

Kreativ-Workshop für Interessierte; dessen Resultate werden vom Projektteam aufge-

nommen und weiterbearbeitet

Projektgegenstand besichtigen und erfahren

Schlüsselpersonen, Promotoren, Entscheidungsträger für die Information einsetzen

Die Sprache der Anspruchsgruppen sprechen und spüren, was sie interessiert

Beim Projektmarketing geht es oft nicht nur um das „Verkaufen“ des Projektes, sondern

um das gleichzeitige Transportieren von Managementbotschaften und Werten, z. B. dass

mit dem Projekt gleichzeitig eine neue Kultur der Zusammenarbeit eingeleitet wird.

Wichtig ist die Grundhaltung beim Marketing: Brillieren, Täuschen, Aufschwatzen,

Mitbeteiligung vortäuschen wirkt höchstens kurzfristig. Um wirklich Vertrauen zu schaf-

fen ist Ehrlichkeit, Transparenz und Wertschätzung gefordert.

Das Projektmarketing beginnt bereits während der Initialisierung des Projektes. Die

Bedeutung steigt jedoch in der Realisierungsphase, wenn es in Richtung Einführung geht

und sich der Kreis der zu informierenden Personen vergrößert.

2.3.7

Prüfung der Machbarkeit

Sorgfältig bearbeitete Vorstudien (Machbarkeitsstudien, Feasibility Studies, Stakeholder-

Analysen usw.) helfen, wesentliche Projektrisiken zu minimieren und den Projektverlauf

effektiv zu gestalten. Die Frage ist zu klären, ob das Projekt machbar ist.

1. Machbarkeit

Am Ende der Initialisierung muss geklärt sein, ob das Vorhaben erfolgreich durchgeführt

werden kann. Zur Beurteilung der Machbarkeit eines Vorhabens kann die Klärung der

folgenden Fragen einen wertvollen Beitrag leisten:

Ist das Projekt technisch und politisch machbar?

Können die verschiedenen Unsicherheiten durch das Projekt reduziert werden?

Sind Know-how und Ressourcen vorhanden, dass das Vorhaben in Angriff genommen

werden kann?

Ist das Projekt ﬁnanziell und auch terminlich machbar?

Werden die Ressourcen für dieses Projekt richtig eingesetzt?

Welche Szenarien sind grundsätzlich vorhanden, um das Globalziel zu erreichen?

Ist die Machbarkeit eines Vorhabens nach einer ersten Prüfung nicht gegeben, können

mit einer Simulation mehrere Parameter in Form verschiedener Szenarien durchgespielt

werden. Wenn die Simulation zeigt, dass Kosten und Nutzen nicht in einem guten Verhält-

nis sind, muss ein Stopp des Vorhabens beantragt werden.

100

Methodik

Unter Machbarkeit geht es auch um die Einschätzung aufgrund der Stakeholder-Ana-

lyse, wieweit die zwischenmenschlichen Rahmenbedingungen die Abwicklung des Pro-

jektes gefährden können. Hier spielen folgende Faktoren eine Rolle:

Wird der Projektleiter von den Beteiligten respektiert und als Abwicklungsbeauftragter

akzeptiert?

Steht die Linie überhaupt hinter dem Projekt, oder ist Widerstand zu erwarten?

2. Wirtschaftlichkeit

Bereits im Business Case (Abschn. 2.2.3) wurden Überlegungen zur Wirtschaftlichkeit ge-

macht. Nun sind diese Angaben nochmals zu veriﬁzieren und bei Bedarf anzupassen. Mit

einer Beurteilung der Projektwirtschaftlichkeit sollen vor allem zwei Fragen beantwortet

werden:

Welche Gewinne, Kostenreduktionen oder Einsparungen bringt das Projekt?

Wie risikoreich oder rentabel ist ein Kapitaleinsatz ins Projekt?

2.3.8

Risikomanagement

Das Risikomanagement im Rahmen eines Projekts soll nicht nur die oft gut in den Un-

ternehmensprozessen abgebildeten Produktrisiken, sondern insbesondere die eigentlichen

Projektrisiken abdecken. In vielen Unternehmen werden Projekt- und Produktrisiken in

einer gemeinsamen Risikoanalyse betrachtet. Bei der folgenden Konzentration auf Pro-

jektrisiken gelten die Überlegungen sinngemäß auch für Produktrisiken. Abb. 2.13 zeigt

den Ablauf des Risikoprozesses.

Auf die gleiche Art wie Risiken bearbeitet werden, können auch Chancen identiﬁziert

und realisiert werden.

2.3.8.1

Die konkreten Schritte im Risikoprozess

Da in einem Projekt eine Vielzahl von nicht absehbaren Risiken auftauchen kann, muss

eine Beurteilungsmethode für potenzielle Projektrisiken etabliert werden. Je nach Projekt-

phase können neue Risiken eintreten, für welche entsprechende Maßnahmen entwickelt

werden müssen. Dieser Risikoprozess muss im Laufe eines Projektes regelmäßig durch-

laufen werden.

1. Risiken identiﬁzieren

Für die Identiﬁkation potenzieller Risiken stehen je nach Projektphase verschiedene Hilfs-

mittel zur Verfügung. Vielfach genügt eine Analyse des Projektumfeldes z. B. auf der

Basis einer Stakeholder-Analyse, um eine erste grobe Risikoabschätzung durchzuführen.

Es geht in erster Linie darum, die wichtigsten Risikokategorien zu identiﬁzieren, wie

Tab. 2.11 zeigt.

2.3

Phase Initialisierung

101

• Alle möglichen

Risiken (Felder)

identiﬁzieren

• Alle risiko-

relevanten Infor-

mationen sammeln

Identiﬁkation

Risikoprozess

• Identiﬁzierte Risiken

bewerten und

gewichten

• Wahrscheinlichkeit

des Eintretens, Aus-

masses abwägen

Quantiﬁzierung

• Massnahmen

entwickeln und

Aktionen vorbereiten:

Vermeiden

(präventiv)

Vermindern

(präventiv, reaktiv)

Abwälzen (Versiche-

rung, Vertrag)

Akzeptieren

(bewusst tragen,

planen)

• Regelmässig

kontrollieren und

Status bekannt geben

• Sicherstellen, dass

neue Risiken erkannt

werden

Kontrolle

Abdeckung

Abb. 2.13 Der Risikoprozess

Tab. 2.11 Beispiele für Risikokategorien

Beispiele

für Risiko-

kategorien

– Methodische Risiken (Komplexität, Vorgehen)

– Technologische Risiken (neue Produkte, Materialeigenschaften usw.)

– Wirtschaftliche Risiken (Kostendach, Bonität der Geschäftspartner usw.)

– Personelle Risiken (Verfügbarkeit, Befangenheit, Dilemma bei verschiedenen

Rollen, Krankheit, Kündigung usw.)

– Politische Risiken (Änderung der Unternehmensstrategie, Gesetzgebung)

– Wettbewerbs- und Marktrisiken (Konkurrenzprodukt ist besser oder billiger)

– Rechtliche Risiken (Produktehaftung, Verträge usw.)

– Umfeld-Risiken

2. Risiken quantiﬁzieren

Um die Risiken zu beziffern, stehen sowohl qualitative wie auch quantitative Metho-

den zur Verfügung. In diesem Schritt geht es primär darum, die „Höhe“ des Risikos zu

beschreiben. Aus den zwei folgenden Kenngrößen kann dann das Risiko quantitativ be-

schrieben werden:

Risiko D Eintrittswahrscheinlichkeit Schaden

102

Methodik

gross

mittel

gering

Risiko

Problemlos

Hoch riskant

Wahrscheinlichkeit

Schaden

Abb. 2.14 Ausmaß von Risiken

Die Eintrittswahrscheinlichkeit kann in Wahrscheinlichkeitsklassen wie in Abb. 2.14

gezeigt, eingeteilt oder in Prozent abgeschätzt werden.

Der Schaden wird häuﬁg monetär quantiﬁziert oder als Zeitverzug dargestellt.

Anstelle einer vermeintlich präzisen Berechnung des Risikos reicht es in der Praxis in

vielen Fällen aus, das Risiko bezüglich Eintrittswahrscheinlichkeit und Schaden einzu-

schätzen, wie in Abb. 2.14 gezeigt.

In Abb. 2.15 wird die Risikomatrix und in Abb. 2.16 wird die Beschreibung der Top-

Risiken des Praxisbeispiels BLS gezeigt.

Es empﬁehlt sich, die Einschätzung der Eintrittswahrscheinlichkeit und des zu erwar-

tenden Schadens im Projektteam vorzunehmen. Eine gemeinsam erarbeitete Sicht fördert

das Verständnis und erhöht die Sensibilität gegenüber den kritischen Risiken durch das

Projektteam. Für diese Einschätzung können auch die Karten aus dem Planning Poker

(siehe Abschn. 2.4.6.2) eingesetzt werden.

Mit einer Sensitivitätsanalyse wird der Einﬂuss jeweils eines Parameters (z. B. Betrach-

tungsdauer, Zinssatz, jährliche Erträge usw.) betrachtet. Das heißt es wird untersucht, wie

empﬁndlich die Parameter auf kleine Änderungen reagieren. Dies kann mithelfen, hei-

kle Annahmen bzw. kritische Parameter aufzuzeigen, um sie bei der Umsetzung intensiv

überwachen zu können.

2.3

Phase Initialisierung

103

Risiken

Übersicht alle Risiken

)

( tie

cilnie

70-

100

30-

klein

mittel

gross

Auswirkung (A)

R1: Einführung öV Plattform

R2: NOVA Pilot

R3: Knappe Ressourcensituation bei der

BLS

R4: Projekt wird überladen

R5: Abhängigkeit zu anderen Projekten

(CEM, bls.ch, ESB, S16)

R6: Qualität der Kostenschätzungen

R9: Erfahrung mit agilem Vorgehen

R10: Einhaltung Pace durch

Projektteam

R12: Koordinationsschwierigkeiten zw.

BLS, PAG, SOB und ZVV

R13: Entscheid Aufschaltung TUs durch

ZPS im Q3/2016

R14: Laufende Veränderungen NOVA

Schnittstelle

R10

R13

R14

R12

Abb. 2.15 Praxisbeispiel BLS: Risikomatrix

Risiken

Beschreibung der Top-Projektrisiken

Risiko

Beschreibung

Auswirkungen

Massnahmen

Trend

Projekt wird überladen,

grosse Projektkomplexität,

parallele Grundsatzab-

klärungen

Change Requests

Die Ablösung der Vertriebs-

kanäle oder Entwicklung von

neuen Kanälen wird

im Projekt gemacht

Belastung im Projekt steigt

mit Grundsatzklärungen

Parallele Grundsatzabklär-

ungen rasch vorantreiben

Abhängigkeit zu anderen

Projekten (CEM, bls.ch, ESB,

S16)

Anforderungen / Anfragen

aus verknüpften Projekten

Abstimmungsmeetings

(Trident+)

Qualität der Kosten-

schätzungen

Kostenüberschreitungen

Regelmässige Evaluation der

Annahmen, die dem Projekt

zugrunde liegen

Identifikation und Monitoring

der Kostentreiber

Starker Einbezug des

Controllings

Massnahmen zeigen Wirkung (Verbesserung)

Keine Abweichung absehbar

Abweichungen absehbar (Verschlechterung)

Abb. 2.16 Praxisbeispiel BLS: Beschreibung der Top-Projektrisiken

104

Methodik

Tab. 2.12 Maßnahmen zur Reduktion von Risiken

Vermeiden

Wie kann ein Risiko überhaupt vermieden bzw. eliminiert werden?

! Lösungen entwickeln, welche das Risiko nicht enthalten

Vermindern

Wie kann ein Risiko vermindert bzw. reduziert werden?

Wirkt die Maßnahme auf die Eintretenswahrscheinlichkeit, auf das Schadensaus-

maß oder auf beide?

! Verbesserungspotenzial ausloten, Alternativ-Szenarien prüfen (z. B. Zweit-

Lieferant)

Abwälzen

Wie kann ein Risiko auf Andere abgewälzt werden?

! Vertragsanpassungen (z. B. Gewährleistung einschränken, Konventionalstrafe

vereinbaren), Versicherung, Absicherung von Währungswechselkursen

Bewusst

tragen

Wie kann ein Risiko getragen werden?

! Im Projektplan und Budget vorsehen, Rückstellungen bilden, dokumentieren

und kommunizieren (Kunde, Entscheidungsträger)

Eine Methode, die dem Grundgedanken der Sensitivitätsanalyse nachgeht und sich in

vielen Branchen und Unternehmen durchgesetzt hat, ist FMEA, die Fehlermöglichkeiten-

und Einﬂussanalyse, siehe Abschn. 2.3.8.2. In einigen Branchen wird sie obligatorisch

eingesetzt für jedes System und jede Komponente, die neu entsteht, auch von allen Zulie-

ferern (Automobilbau, Medizintechnik). In anderen Branchen wurde diese Methode den

unterschiedlichen Bedingungen angepasst, z. B. in der Nahrungsmittelbranche (HACCP,

Hazard Analysis and Critical Control Points).

Eine weitere Möglichkeit, die Risiken einzuschätzen, ist die Simulation. Mit ihr können

mehrere Parameter in Form verschiedener Szenarien durchgespielt werden.

3. Risiken abdecken

Damit ein Projekt trotzdem durchgeführt werden kann bzw. das Risiko für das Unterneh-

men tragbar wird, sollen gezielte, vorbeugende Maßnahmen entwickelt werden, welche

das Risiko auf ein vertretbares Maß reduzieren. Die grundsätzlichen Maßnahmen gemäß

Tab. 2.12 können hilfreich sein.

In einem Risikomanagement-Tool werden nun alle identiﬁzierten Risiken aufgelistet

und bewertet. Pro Risiko werden Maßnahmen deﬁniert. Deren Einﬂuss auf das Risiko

wird dargestellt. In der Praxis wird das Risikomanagement-Tool oft in einem Tabellen-

verarbeitungsprogramm abgebildet; der Markt bietet auch speziﬁsche Software-Lösungen

an.

Tab. 2.13 zeigt eine exemplarische Risikoliste mit qualitativer Risikobeurteilung je-

weils vor und nach Umsetzung der entsprechenden Maßnahmen.

Neben den in Tab. 2.12 aufgezeigten Maßnahmen zur Reduktion von Risiken können

für die Bewältigung auch bewusste Risikostrategien, wie in Abb. 2.17 gezeigt, gewählt

werden.

2.3

Phase Initialisierung

105

Tab. 2.13 Beispiel einer Risikoliste

Risiko

Maßnahme

Kosten

Entscheid

Zwei Wochen Mei-

lenstein-Verzug durch

Mitarbeiterengpass we-

gen Arbeit an mehreren

Projekten

Klare Kommu-

nikation der

Projektprioritäten

gemäß Portfolio

1/4 h an

Projekt-

sitzung

Umsetzen

Ausfall der bestehenden

Testanlage zur Überprü-

fung der Prototypen

Beschaffen einer

zweiten Testanla-

ge als Backup

C 35k

Nicht

umsetzen

Legende:

E = Eintretenswahrscheinlichkeit; S = Tragweite des Schadens auf einer Skala von 1 bis 10;

R0 = Risiko vor Umsetzung der Maßnahme; R1 = Risiko nach Umsetzung der Maßnahme

niedrig

schlecht

hoch

gut

eigene Reaktionsfähigkeit auf Ereignisse/Änderungen

Prognostizierbarkeit der Ereignisse/Änderungen

mehrere Szenarien

vorbereiten und

bei Bedarf danach

handeln

Vorüberlegungen

machen und bei

Bedarf entschlossen

handeln

mehrere Alternativ-

Lösungen parallel

bearbeiten

aufmerksam beobachten

und sofort reagieren

Risiko

Abb. 2.17 Risikostrategien

Für Risiken, welche durch das Projekt beeinﬂussbar sind, können Maßnahmen ent-

wickelt oder die FMEA (Abschn. 2.3.8.2) angewendet werden. Trotz aller Maßnahmen

verbleiben Risiken, die durch das Projekt kaum beeinﬂussbar sind. Auf diese kann sich

der Projektleiter nur einstellen und sie laufend aufmerksam beobachten.

106

Methodik

4. Risiken kontrollieren

Die Umsetzung der deﬁnierten Maßnahmen muss laufend überwacht werden. Daneben

gilt es, den Risikoprozess periodisch zu durchlaufen. Damit wird sichergestellt, dass neue

Risiken identiﬁziert und die Quantiﬁzierung der identiﬁzierten Risiken überprüft und bei

Bedarf angepasst werden.

2.3.8.2

Failure Mode and Effect Analysis (FMEA)

Eine FMEA (Fehlermöglichkeit- und Einﬂussanalyse) kann in verschiedenen Stadien ei-

nes Projekts durchgeführt werden, man unterscheidet insbesondere folgende Arten von

FMEA:

Design FMEA (auch Konzept FMEA genannt)

System-FMEA (auch Produkt FMEA genannt)

Prozess FMEA (auch Produktions-FMEA genannt)

Alle potenziellen Fehler, die in den unterschiedlichsten Situationen denkbar sind, wer-

den aufgelistet. Dann werden schwerpunktmäßig vorbeugende Maßnahmen ergriffen. De-

ren Wirksamkeit wird laufend überprüft. Vorgehensschritte einer FMEA:

Alle denkbaren Fehler, Ausfälle bzw. Probleme auﬂisten

Mögliche Folgen des Ausfalls bzw. Problems angeben

Mögliche Ursachen und Korrekturmaßnahmen formulieren

W = Eintretenswahrscheinlichkeit [1 . . . 10]

T = Tragweite, Auswirkungen des Fehlers [1 . . . 10]

E = Entdeckungswahrscheinlichkeit im Unternehmen [10 . . . 1]

Die Entdeckungswahrscheinlichkeit ist an einen Zeitpunkt gekoppelt. Es macht einen

großen Unterschied, ob ich einen Fehler früh oder spät erkenne. Die Werte W, T und E

werden in einer genau deﬁnierten Werteskala ausgedrückt. Neben der hier gezeigten Skala

1 . . . 10 wird oft auch eine Skala von 1 . . . 6 verwendet. Das Produkt dieser drei Größen

ist die Risikoprioritätenzahl:

W T E D Risikoprioritätenzahl (RPZ)

Je höher die Risikoprioritätenzahl, desto sinnvoller und notwendiger ist die Durch-

führung vorbeugender Maßnahmen. Vor allem, wenn auch noch ein günstiges Aufwand-

Nutzen Verhältnis vorliegt.

Abb. 2.18 zeigt ein Beispiel einer FMEA-Analyse. Das Unternehmen deﬁniert eine

obere Grenze für die Risikoprioritätenzahl. Das Qualitätsverständnis der Organisation

lässt nur Risiken unter dieser Grenze zu. Wird der Grenzwert überschritten, müssen vor-

beugende Maßnahmen eingeleitet und deren Wirksamkeit überprüft werden. Die neue

Risikoprioritätenzahl nach Durchführung der Maßnahmen wird ermittelt. Sie muss eben-

falls unter dem Grenzwert liegen.

2.3

Phase Initialisierung

107

RPZ

R1 Präzision des

Dosieres erfüllt

geforderte

Messgenauigkeit

nicht

Anwender hat

ungenaue und

schwankende

Ergebnisse

* Ventile arbeiten nicht

korrekt

* Antriebssteuerung

ungenau

* Wartezeiten bei Be-

wegungsänderungen

nicht ausreichend

240

Ventile optimieren durch

Materialwahl-

Verbsserung, Abtesten

aller Varianten

Antriebsteuerung

durch den Einbau

eines hochwertigen

Linearweg-

Messsystems

optimieren

Wartezeiten

anhand

bestehendem

Dosiersystem

ermitteln,

Dosiergenauigkeit

bei verschiedenen

Wartezeiten prüfen

R2 Neue Ventil-

technologie

funktioniert nicht

Dosiergenauigkeit

wird nicht erreicht

* Verstopfen der Ventile

180

Alternativ-Lösung:

benutzen der

existierenden

Ventiltechnologie

R3 ASIC steht nicht

funktionsfähig

zeitgerecht zur

Verfügung

Test des Systems

kann nicht wie ge-

plant starten. Ge-

ringe Wahrschein-

lichkeit, die Verzö-

gerung nicht recht-

zeitig zu erkennen

* ASIC Technologie hat

lange Design-Loops

* Nicht genügend

Ressourcen

448

Mehr Ressourcen zur

Verfügung stellen,

externe Unterstützung

einholen

Testbeginn durch

Einbindung

bestehender ASIC

ermöglichen

Klare Priorisierung

der Funktionen,

später benötigte in

einen späteren

Design-Loop

einplanen

R4 UL-Zertifizierung

wird nicht erreicht

Verkauf im

nordamerika-

nischen Markt wird

schwierig

* Verwendung nicht UL-

zertifizierter Kompo-

nenten

keine Massnahmen

notwendig

R5 Software steht

nicht ausreichend

funktionsfähig zur

Verfügung

Markteinführung

des Systems kann

nicht wie erwünscht

erfolgen. Die Verzö-

gerung wird spät

erkannt

* SW Backlog wird

nicht zeitgerecht

abgearbeitet

360

Mehr Ressourcen zur

Verfügung stellen,

externe Unterstützung

einholen

Backlog mit

erfahrenen

Fachpersonen

priorisieren

Beurteilung nach

Massnahmen

Zustand aktuell

Massnahmen

verbesserter

Fehler-Möglichkeiten und Einfluss-Analyse

EWP100 OMNIS Titriersystem

Fehler

Folgen

Ursachen

Beurteilung vor Massnahmen

Massnahmen

rote Felder müssen mitigiert werden

Abb. 2.18 Praxisbeispiel Metrohm: FMEA-Analyse

108

Methodik

Tab. 2.14 Wichtige Voraussetzungen für eine gut funktionierende Projektorganisation

Wichtige Voraus-

setzungen für eine

gut funktionierende

Projektorganisation

– klare Projektvereinbarung: herausfordernde Zielsetzung und Rahmen-

bedingungen bzw. Leitplanken, welche den Spielraum deﬁnieren

– klare und ausreichende Entscheidungskompetenz und entsprechende

Führungsverantwortung der Projektleitung, beziehungsweise des Pro-

duct Owners und Scrum Masters

– adäquate interdisziplinäre Fachvertretung und Fachkompetenz im Pro-

jektteam

– aktive Benutzer und Betroffene, um möglichst hohe Akzeptanz zu er-

reichen

– Arbeitskultur, welche Kommunikation, Engagement und Kreativität

fördert

– gute Verankerung in der Stammorganisation, möglichst bei den rele-

vanten Entscheidungsträgern „angebunden“

– Verfügbarkeit der Ressourcen

2.3.9

Projektorganisation/Rollen/Gremien

Die Projektorganisation ist eine temporäre Organisation für die Dauer des Projektes.

Ihre Notwendigkeit ergibt sich daraus, dass die bestehende Linienorganisation für die Er-

füllung ihrer Fachaufgaben optimiert ist, jedoch nicht für die Führung und Bearbeitung

neuartiger, einmaliger und fachübergreifender Vorhaben. Ihr fehlt auch die nötige Fle-

xibilität, um bei Problemen und Änderungen entsprechend rasch reagieren zu können.

Tab. 2.14 zeigt die wichtigen Voraussetzungen für eine gut funktionierende Projektorga-

nisation.

Es ist wichtig, in der formellen Projektorganisation zu regeln, wer welche Rollen, Auf-

gaben, Verantwortungen und Kompetenzen übernimmt. Ist dies sauber aufgesetzt und gut

abgestimmt, so ist dies ein wichtiger Grundstein für den Erfolg des Projektes. Neben der

formellen Organisation werden im Verlaufe der Projekte immer wieder einzelne Personen

oder Personengruppen außerhalb der formellen Projektorganisation versuchen, auf das

Projekt Einﬂuss zu nehmen und damit auch informelle Macht auszuüben (Abschn. 4.1.3).

Für die Projektverantwortlichen ist es von essentieller Bedeutung, diese informelle Ein-

ﬂussnahme zu erkennen und gewinnbringend für das Projekt zu nutzen. Oft werden rele-

vante Entscheide auf diesen informellen Wegen gefällt und später noch in der formellen

Projektorganisation gutgeheißen.

2.3.9.1

Linie und Projekt: zwei unterschiedliche Welten

Werden in einem Unternehmen spezielle Problemstellungen durch Projektteams bear-

beitet, bedeutet dies, dass neben der Linienorganisation eine weitere Arbeitsformation

zugelassen wird, welche sich von ihr unterscheidet:

in der Kompetenzregelung,

in der Art der Zusammenarbeit,

2.3

Phase Initialisierung

109

Linienkultur

hierarchisch, vorgegebene

Berichtswege und

Entscheidungsstrukturen

Projektkultur

Team-betont,

simultane Zusammenarbeit,

vernetzte Kommunikation

Linienwelt

Projektwelt

Abb. 2.19 Zwei Welten – Stammorganisation und Projekt

in der Konﬂiktkultur,

in der Kommunikation,

im Umgang mit Tabus

Diese Unterscheidung soll ganz bewusst gestaltet werden. Sie kann je nach Projekt

markant bis überhaupt nicht ausgeprägt sein. Beispiel: Die Einführung von neuen Pro-

duktionsstrukturen, die eine neue Art der Zusammenarbeit erfordern, kann wesentlich

dadurch unterstützt werden, indem die zukünftige Kultur möglichst schon im Projekt ge-

lebt wird. In Standardprojekten jedoch sind Projektkultur und Unterstellungsverhältnisse

der Stammhierarchie näher, die Unterschiede zwischen den zwei Welten sind minimal.

Abb. 2.19 zeigt den Unterschied zwischen der Linienorganisation und der Projektorgani-

sation.

2.3.9.2

Die Rollen und Gremien

In Projektorganisationen werden oft Personen eingesetzt ohne eine genaue Vorstellung,

welche Rolle sie innehaben werden. Das hat zur Folge, dass Rollen unklar deﬁniert und

abgegrenzt sind, oder sogar fehlen. Beispiel: Der Auftraggeber, der auch gerne im Team

mitarbeitet, entscheidet durch seine vorgegebene Machtstellung „von oben“ (wie es auch

110

Methodik

von ihm erwartet wird) und im Team als Teamplayer „von unten“. Die Projektleitung

kommt durch diese Doppelrolle des Entscheidungsträgers in einen Rollenkonﬂikt. Solche

Doppelrollen sollen zu Projektbeginn geklärt werden.

Mehrfachrollen sind gefährlich. In kleinen Projekten sind vollständige Rollenteilungen

natürlich nicht bis in die letzte Konsequenz möglich. Dann sollten aber möglichst „Nach-

barrollen“ mit der gleichen Person besetzt werden, z. B. der Projektleiter arbeitet auch

inhaltlich am Projekt.

Mehrere Rollen bilden zusammen ein Gremium (z. B. Projektausschuss). Die Gremien

und Rollen – oft auch als Projektorgane bezeichnet – werden je nach Projekt und Unter-

nehmenskultur (und Branchenkultur) so gebildet und benannt, dass alle Kompetenzebenen

vertreten sind und das Projektziel möglichst effektiv erreicht werden kann. Oft weiß man

nicht so recht, wer entscheidet. Die Rolle des Projektleiters wird als notwendiges Übel

aufgefasst und daher nur marginal wahrgenommen.

Das Projekt muss in der Entscheidungsebene klar verankert sein. Der Entscheidungs-

prozess muss transparent gemacht werden. Weitere Ausführungen zum Thema Position

und Rolle sind in Abschn. 4.1.9 weiter ausgeführt.

2.3.9.3

Kompetenzen und Führungsaufgaben in der Projektorganisation

Die Kompetenzen der verschiedenen Rollen und Gremien unterscheiden sich teilweise in

der agilen und klassischen Vorgehensweise. Tab. 2.15 zeigt die institutionellen Rollen und

Gremien mit ihren jeweiligen Schwerpunkten auf der Kompetenzebene.

Damit ein Projektteam effektiv arbeiten kann, müssen von Projektleiter, Product Owner

oder Scrum Master vielfältige Führungsaufgaben und Serviceleistungen wahrgenommen

werden. Diese werden in Kapitel Kap. 4 ausführlich beschrieben. In der Tab. 2.16 werden

beispielhaft einzelne Aspekte aufgeführt.

2.3.9.4

Projektorganisation in der agilen Vorgehensweise

Die Projektorganisation (siehe Abb. 2.20) in der agilen Vorgehensweise nach Scrum be-

steht aus den folgenden Rollen:

Product Owner

Team

Scrum Master

Agile Teams sind selbstorganisiert (Abschn. 4.1.12). Jede Rolle in der agilen Projektor-

ganisation hat speziﬁsche Aufgaben zu erledigen, welche in Tab. 2.17 beschrieben werden.

2.3

Phase Initialisierung

111

Tab. 2.15 Rollen und Gremien mit ihren jeweiligen Schwerpunkten auf der Kompetenzebene

Rolle/Gremium

Agil

Klassisch

Auftraggeber – was?

– Entscheidungskompetenz bezüg-

lich Stoßrichtung Projekt

– Sozialkompetenz

– Verhandlungskompetenz

– Fachkompetenz

– Entscheidungskompetenz bezüg-

lich Stoßrichtung Projekt

– Sozialkompetenz

– Verhandlungskompetenz

– Fachkompetenz

Projektausschuss –

was?

– Vorentscheidungsinstanz

– Verbindung Projekt – Linie

– Vorentscheidungsinstanz

– Verbindung Projekt – Linie

Projektleiter – was &

wie?

– Selbstkompetenz

– Sozialkompetenz

– Verhandlungskompetenz

– Team- und Führungskompetenz

– Methodenkompetenz

– Entscheidungskompetenz im

Rahmen des Projektes

Product Owner – was

& wie?

– Selbstkompetenz

– Sozialkompetenz

– Verhandlungskompetenz

– Fachkompetenz

– Entscheidungskompetenz im

Rahmen des Projektes

Scrum Master – wie?

– Selbstkompetenz

– Sozialkompetenz

– Team- und Führungskompetenz

– Methodenkompetenz

Projektteam – wie?

– Team- und Führungskompetenz

bezüglich Selbstorganisation

– Fachkompetenz

– Entscheidungskompetenz was

in den nächsten Sprint kommt

– Fachkompetenz

Nichthierarchische, netzwerkartige Projektorganisation

Ähnlich wie im Scrum sind nichthierarchische, selbstorganisierte Projektorganisationen

besonders für hochkomplexe und dynamische Projekte sehr effektiv. Die Praxis hat ge-

zeigt, dass diese in Projekten mit großem Gestaltungsspielraum und sorgfältig erarbei-

teten Rahmenbedingungen und Spielregeln sehr gut „funktionieren“. Für umfangreiche

Projekte sind mehrere parallel laufende Teams möglich, die untereinander vernetzt sind.

Durch die direkte Vernetzung wird die Koordination besser gewährleistet als durch einen

zentralen Koordinator. Diese Teams sind selbstorganisiert, und die Beziehungen zum Auf-

traggeber und einem allfälligen Projektausschuss sind nichthierarchisch gestaltet.

112

Methodik

Tab. 2.16 Unterschiedliche Aufgaben

Team-

entwicklung

– Sich um das Beziehungsgefüge, das Gruppenklima kümmern, d. h. dafür sorgen,

dass eine Atmosphäre herrscht, in der die Mitglieder arbeitsfähig werden bzw.

bleiben

– Begegnungsmöglichkeiten schaffen, welche die Mitglieder einander näher-

bringen

– Bei der Bewältigung von Spannungen und Konﬂikten helfen, d. h. Unterstüt-

zung für die Bearbeitung unterschwelliger Themen geben

– Darauf achten, dass kein Mitglied in seiner Würde verletzt oder geringschätzig

behandelt wird

Konﬂikt-

management

und Krisen

– Laufende Beobachtung möglicher Anzeichen von Krisen und Konﬂikten

– Vermutete oder offensichtliche Konﬂikte und Krisen als solche klar ansprechen

– Konﬂikte und Krisen im Team bearbeiten und bewältigen

Sitzungen

leiten und

moderieren

– Sitzungen strukturieren und leiten

– Alle Mitglieder einbeziehen und am Lösungsprozess beteiligen

– „Treten an Ort“ verhindern, Entscheidungen provozieren und die Gruppe vor-

wärtstreiben

– Für den richtigen Methoden-Mix sorgen (z. B. Einzel-, Kleingruppen- und

Plenumsarbeit; Brainstorming, usw.). Passende Visualisierungen einsetzen

(Pinnwand, Flipchart, Beamer usw.).

– Den Arbeitsprozess laufend visualisieren und dokumentieren

– Auswertungsrunden initiieren und leiten: „Wer macht was bis wann?“ und „Wie

haben wir gearbeitet?“

Product Owner

Scrum Master

Team

Abb. 2.20 Scrum Projektorganisation

2.3

Phase Initialisierung

113

Tab. 2.17 Aufgaben der einzelnen Rollen und Gremien in der agilen Projektorganisation

Rolle/Gremium Aufgabe

Auftraggeber

Der Auftraggeber nimmt in der agilen Vorgehensweise weniger stark Einﬂuss

auf das Projekt wie in der klassischen Vorgehensweise. Trotzdem hat der Auf-

traggeber die folgenden Aufgaben zu erfüllen:

– Strategische Rahmenbedingungen abstecken

– Product Owner unterstützen, ihm Rückendeckung geben

– Ressourcen zusichern

– Türen öffnen, etwa für wichtige Informanten

– Seine Motivation zeigen (etwa bei Kick-off-Veranstaltungen)

Projektaus-

schuss/Steering

Committee

Der Einsatz eines Projektausschusses in der agilen Vorgehensweis ist optional.

Alternativ könnten die wichtigen Stakeholder zu den Sprint Reviews eingeladen

werden. Dadurch können Sie dem Projekt wertvollen Input liefern.

Product Owner

Der Product Owner steuert das Team auf der inhaltlichen Ebene, indem er

festlegt, was umgesetzt wird. Er führt den Product Backlog und ist für die Wert-

maximierung verantwortlich. Die Aufgaben des Product Owners lassen sich

wie folgt zusammenfassen:

– ist für das Erfassen der Kundenbedürfnisse und die Beschreibung der Anfor-

derungen verantwortlich

– führt, verfeinert und priorisiert den Product Backlog

– ist für das Erreichen der Projektziele und des Return of Investment verant-

wortlich

– erstellt und aktualisiert den Releaseplan und entscheidet alleine über den

Auslieferungszeitpunkt von realisierten Funktionalitäten

– stellt das Stakeholder-Management sicher

Der Product Owner kann sich bei der Erledigung seiner Aufgaben durch das

Team unterstützen lassen. Damit der Product Owner und das Projekt erfolgreich

sein können, muss die ganze Organisation seine Entscheidungen respektieren

und akzeptieren. Der Product Owner muss von der Organisation bevollmäch-

tigt sein (Geliehene Macht Abschn. 4.1.3). Der Job als Product Owner ist ein

Fulltime-Job und kann nicht nebenbei gemacht werden. Ist der Product Owner

nicht verfügbar, so bleiben Fragen unbeantwortet, Unklarheiten können nicht

bereinigt werden. Das führt zu Inefﬁzienzen beim Team.

Scrum Master

Der Scrum Master hilft dem Product Owner und dem Team, Scrum richtig

einzusetzen. Er ist der Methodenspezialist. Je weniger es den Scrum Master

braucht, umso besser hat er seinen Job gemacht. Die Aufgaben des Scrum Mas-

ters sind:

– Scrum etablieren, die notwendigen Techniken vermitteln und helfen, die Pro-

zesse zu etablieren

– das Team unterstützen und den Projektmitarbeitenden helfen, ihre Aufgaben

effektiv zu erledigen

– die direkte Zusammenarbeit zwischen Product Owner und Team sicherstellen

– Hindernisse beseitigen

– die Entwicklungspraktiken zu verbessern helfen

Der Scrum Master ist ein guter Zuhörer. Mit seiner Persönlichkeit ist er auch

in der Lage, das Team in schwierigen Situationen zu unterstützen. Der Scrum

Master wendet die Instrumente der Moderation und des Coachings an. Je nach

Projekt ist die Aufgabe des Scrum Masters am Anfang ein 100 %-Job. Im Ver-

laufe des Projektes wird jedoch seine Belastung sinken, und es ist durchaus

möglich, dass ein Scrum Master dann zwei oder drei Projekte betreut.

114

Methodik

Tab. 2.17 (Fortsetzung)

Rolle/Gremium Aufgabe

Team

Das Team führt die Arbeiten aus und stellt die Realisierung der Anforderungen

sicher. Das Team besteht aus Fachleuten, die am Ende eines Sprints ein fertiges

Inkrement ausliefern. Das Team setzt sich aus den Spezialisten zusammen, die

notwendig sind, um die Aufgabe zu bewältigen. Die Mitarbeiter in einem Team

müssen über das relevante Wissen und die notwendigen Fähigkeiten verfügen

und efﬁzient miteinander zusammenarbeiten können. Ist dies nicht sicherge-

stellt, so ist das Team meist wenig produktiv. Ein gut funktionierendes Team

weist folgende Eigenschaften aus:

– Das Team organisiert sich selbst und ist autonom

– Es entscheidet, wie viele Anforderungen innerhalb des nächsten Sprints um-

gesetzt werden

– Das Team ist interdisziplinär tätig

– Es gibt keine weiteren Unterteilungen im Team

– Die Rechenschaft obliegt dem ganzen Team und kann nicht an eine einzelne

Person delegiert werden.

– Die Teammitglieder sind in der Regel zu 50 bis 100 % ihrer Kapazität im

Team und arbeiten nach Möglichkeit in unmittelbarer Nähe zusammen

Die ideale Teamgröße ist zwischen drei und neun Mitgliedern. Wenn mehr als

neun Mitglieder notwendig sind, um ein Projekt zu realisieren, werden idea-

lerweise parallel arbeitende Teams gebildet. Dabei kann der Ansatz von Large

Scale Scrum (Less) verfolgt werden. Die Realisierung von Projekten mit meh-

reren parallel arbeitenden Teams ist sehr anspruchsvoll und verlangt von allen

Beteiligten viel Erfahrung. Im Setting mit mehreren Teams gibt es nur einen

Product Owner.

Das Management muss sich ausdrücklich zur Selbststeuerung (Abschn. 4.1.12) be-

kennen, denn es delegiert einen Teil ihrer Entscheidungsmacht und muss das Projekt

entsprechend unterstützen (Abschn. 4.1.3). Als Auftraggeber deﬁniert es den Projektauf-

trag, d. h. den inhaltlichen Rahmen und die Spielregeln. Der Auftraggeber ist somit eher

Kunde und vereinbart mit dem Team den Auftrag.

Die „Projektleitung“ kann zwei Ausprägungen haben:

In hybriden Projekten ist der „agile Projektleiter“ für die Gesamtplanung verantwort-

lich (Kolb 2014).

In agilen Projektteilen ist der „Teamcoach“ bzw. Scrum Master für die Unterstützung

des Teams zuständig.

Je nach Projekt können beide Rollen in einer Person vereint werden. Grundsätzlich ist

aber zu beachten, dass Projektleiter im Zusammenhang mit selbstgesteuerten Teams nicht

eine leitende, sondern eine organisierende und unterstützende Funktion haben: Sie orga-

nisieren die Nominierung der Teammitglieder, planen und moderieren Meetings wie den

Kick-off oder die Koordinations- und Präsentationsmeetings, schirmen vor Fremdeinﬂüs-

sen ab oder bieten Coaching an.

2.3

Phase Initialisierung

115

Projektteam 3

Projektteam 2

Projektteam 1

Auftraggeber/

Unterstützungs-

team

Product Owner

Organisator/

Teamcoach

Scrum Master

Abb. 2.21 Möglichkeit einer Projektorganisation als Netzwerk. Product Owner und Scrum Master:

Entsprechung zu Scrum

Falls es einen Projektausschuss gibt, hat er nebst den Vorarbeiten (Vision und Leitli-

nien erarbeiten, übergeordnete strategische Arbeiten erledigen usw.) gegenüber dem oder

den Teams ebenfalls eine unterstützende Funktion. In solchen Situationen wird der Pro-

jektausschuss daher auch Unterstützungsteam genannt, wie in Abb. 2.21 aufgezeigt.

2.3.9.5

Projektorganisation in der klassischen Vorgehensweise

Jede Rolle in der klassischen Projektorganisation hat speziﬁsche Aufgaben zu erledigen,

welche in Tab. 2.18 beschrieben werden.

Die idealtypische Projektorganisation ist in Abb. 2.22 dargestellt.

Der Projektleiter sollte Selbstkompetenz, Sozialkompetenz, Verhandlungskompetenz,

Team- und Führungskompetenz und Methodenkompetenz mitbringen. Dabei kann er na-

türlich nicht überall Spezialist sein. Aber er müsste je nach Projekt und Aufgabenstellung

in allen Bereichen die für das Projektmanagement günstigen Kompetenzen mitbringen.

Das heißt bezüglich:

Selbstkompetenz: Sein Mensch- und Weltbild beeinﬂusst, welchen Umgang der Projekt-

leiter mit seinem Team pﬂegt. Auch sein Bewusstsein (Abschn. 3.3.6), seine Motivation

116

Methodik

Tab. 2.18 Aufgaben der einzelnen Rollen und Gremien in der klassischen Projektorganisation

Rolle/Gremium

Aufgabe

Auftraggeber

Synonym verwendete Begriffe sind Project Sponsor, Project Owner, Projekt-

eigner. In den meisten Fällen ist der Auftraggeber auch Entscheidungsträger.

Es sind aber Situationen denkbar, in denen die Entscheidungsfunktion auf-

geteilt wird, z. B. zwischen Geschäftsleitung und Vorstand oder zwischen

Exekutive und Legislative. Im Wesentlichen umfasst die Rolle des Auftrag-

gebers die folgenden Aufgaben:

– Strategische Rahmenbedingungen abstecken

– Prioritäten setzen, welche Projekte wichtig bzw. dringend sind

– Projektauftrag verbindlich vereinbaren

– Meilensteinentscheide treffen

– Projektleitung unterstützen, ihr Rückendeckung geben

– Ressourcen zusichern, die Projektleitung hat nicht die Macht, sich die Res-

sourcen zu nehmen. Hier muss der Auftraggeber Unterstützung bieten

– Türen öffnen, etwa für wichtige Informanten

– Informieren: Oft kann es wichtig sein, dass die Auftrag gebende Stelle nach

außen informiert (Repräsentation)

– Die eigene Motivation zeigen (etwa bei Kick-off-Veranstaltungen)

Projekt-

ausschuss/

Steering Com-

mittee

Der Projektausschuss wird auch Steuergruppe, Lenkungsausschuss,

Steering Committee (SC, SteCo) oder Reviewboard genannt und ist die

fachliche Erweiterung des Auftraggebers. Er nimmt die Rolle der generellen

Steuerung und Vorentscheidung wahr, besonders in großen Projekten. Im

Projektausschuss sind meistens Exponenten des oberen Managements oder

wichtiger Anspruchsgruppen vertreten. Setzt sich die Steuerungsgruppe nur

aus Mitgliedern des oberen Managements zusammen, so kann diese Gruppe

die inhaltliche Steuerung des Projektes oftmals an einen Fachausschuss oder

ein Fach-Review-Board delegieren.

Begleitgruppe/

Sounding

Board

Die Begleitgruppe unterstützt das Projekt, indem sie Stellung nimmt zu wichti-

gen inhaltlichen Ergebnissen. Sie kann sinnvoll sein bei Projekten, in denen

unterschiedliche Anspruchsgruppen vertreten sind. Ziele sind die Ausein-

andersetzung mit dem Projekt und dessen breite Akzeptanz. Begleitgruppen

kommen am ehesten in Forschungsprojekten, Akzeptanzprojekten oder in Ver-

änderungsprojekten vor.

(Abschn. 3.7) und sein Umgang mit Stress (Abschn. 3.5) wird das Verhalten seines Teams

beeinﬂussen.

Sozialkompetenz: Die persönliche Kommunikation (Abschn. 3.9), die interdisziplinäre

Zusammenarbeit und der Umgang mit Konﬂikten (Abschn. 4.4) verlangen vom Projekt-

leiter eine hohe Sozialkompetenz.

Verhandlungskompetenz: In vielen Situationen muss der Projektleiter Verhandlungen

führen (Abschn. 4.3) und einen Ausgleich zwischen Parteien ﬁnden.

Team- und Führungskompetenz: Projektleiter sind Gestalter sozialer Prozesse und müs-

sen vor allem Teams führen können (Kap. 4). Führen ist sehr anspruchsvoll und basiert

stark auf dem Menschenbild des Projektleiters (Kap. 3). Sie verlangt ein hohes Maß an

2.3

Phase Initialisierung

117

Tab. 2.18 (Fortsetzung)

Rolle/Gremium

Aufgabe

Projektleiter

(PL)

Der Projektleiter ist verantwortlich für die operative Abwicklung des Pro-

jektes, ist also Prozessgestalter. Er trägt die Vorgehensverantwortung. In

der Regel nimmt eine Person die Gesamtleitung wahr. Es ist aber auch ein

Leitungsteam denkbar – in diesem Falle müssen aber die sich gegenseitig er-

gänzenden Rollen sehr gut geklärt sein. In großen Kunden- oder Bauprojekten

wird in beiden Firmen (Auftragnehmer und Kunde bzw. Bauherr) je ein Pro-

jektleiter nominiert.

Führung und Organisation:

– Projektvereinbarung mit Auftraggeber aushandeln und schriftlich festhal-

ten

– Eine Problemlösungs- und Vorgehenssystematik wählen und einhalten

– Stakeholder-Management führen und den Einbezug der berechtigen An-

spruchsgruppen sicherstellen (Abschn. 2.3.5)

– Projektteam und Projektorganisation bilden, zusammen mit dem Auftrag-

geber erforderliche Ressourcen beschaffen

– Rollenklärung (Aufgaben- und Rollenteilung) (Abschn. 4.1.9)

– Projektstart, Kick-off durchführen (Abschn. 2.3.14)

– verschiedene Teilprojekte und Aktivitäten koordinieren (Kap. 4)

– Team leiten, Beteiligte koordinieren (Kap. 4)

– Sitzungen und Workshops moderieren

– Konﬂikt- und Krisenmanagement (Abschn. 4.4)

– Risikomanagement etablieren (Abschn. 2.3.8)

Planung

– Termine, Personen, Kosten und Qualität planen, kontrollieren und steuern

– Projektwirtschaftlichkeit beurteilen

– Meilenstein-Entscheide vorbereiten

– Konsequenzen von Zieländerungen aufzeigen

Information und Kommunikation:

– Aktiv und situativ informieren und kommunizieren

– Dokumentation sicherstellen: Protokolle, Projektpläne, Beschreibungen,

Programme usw.

Controlling:

– Ein Kontrollsystem einrichten, welches das Erreichen des Ziels, den Fort-

schritt (Inhalt, Termine) und Aufwand (Zeit und Kosten) überwacht und

Abweichungen meldet

– Zielabweichungen erkennen und Maßnahmen einleiten

Teilprojektleiter

(TPL), Teilpro-

jektteams

In großen Projekten lassen sich autonome Teilprojekte bilden. Die Leitung

dieser Teilprojekte ist Aufgabe des Teilprojektleiters. Die Aufgaben des Teil-

projektleiters sind ähnlich wie die des Projektleiters. Es braucht in jedem Fall

eine klare Absprache über das Aufgabenfeld zwischen PL und TPL.

Projektteam

Das Projektteam hat die Rolle der inhaltlichen Projektbearbeitung. Bei grö-

ßeren Projekten kann es sinnvoll sein, das Team zu strukturieren in Kernteam

und erweitertes Team. Durch diese Strukturierung lassen sich Sitzungen und

Workshops efﬁzienter gestalten. Es müssen nicht alle Mitglieder überall dabei

sein.

Temporäre

Gruppen

Für die Bearbeitung speziﬁscher Aspekte können Arbeitsgruppen ins Leben

gerufen werden, die noch temporärer als das ganze Projekt sind.

118

Methodik

Projektträger

Projektteam

Auftraggeber

Projektausschuss

Kernteam

Projektleiter

Teilprojektteam

Abb. 2.22 Idealtypische Projektorganisation

Sozialkompetenz und Einfühlungsvermögen. Natürlich ist auch diese Kompetenz weit-

gehend von der Projektart abhängig und komplementär zum Fachwissen: Je weniger das

Fachwissen im Vordergrund steht, desto mehr ist Führungskompetenz gefragt und um-

gekehrt. Da der Projektleiter die am Projekt mitarbeitenden Personen nicht administrativ

führt, muss er sich ohne formelle Macht durchsetzen können.

Methodenkompetenz: Gemeint sind Strukturierungs- und Planungsmethoden, Problem-

lösungsmethoden, Moderationstechniken, Vorgehensmethoden usw.

In kleineren Projekten, sowie bei Standard- oder Wiederholprojekten ist es von Vorteil,

wenn der Projektleiter auch über Fachkompetenz verfügt.

2.3.9.6

Projektorganisation in der hybriden Vorgehensweise

In der Einleitung (Abschn. 1.4.3 und 2.1) sind mögliche Organisationsformen für das hy-

bride Projektmanagement beschrieben. Die beste Kombinationsform zwischen agilen und

klassischen Elementen muss situativ für jedes Projekt einzeln bestimmt werden. Abb. 2.23

zeigt die hybride Projektorganisation am Praxisbeispiel BLS.

2.3

Phase Initialisierung

119

Auftraggeber /

Projektausschuss

Gesamtprojektleiter

Product Owner & Change

Log

Fachausschuss

Fachlicher Lead, Prozesse,

Anforderungen, Product Owner

Architektur, Entwicklung

Finance / Controlling

Lieferantenmgt, Testing, IT-Betrieb

IT-Projektleiter, Scrum Master

Prozesse, Anforderungen,

Requirements Engineering

Kommunikation &

Marketing

Betriebsvorbereitung Fach /

Aufbau Kundensupport

Solution Architektur

Entwickler &

Realisierungspartner

Unternehmensarchitektur

Quality Gates

Ausschreibungen

Beschaffung

Einkauf, Legal

IT-Betrieb / Infrastruktur

IT Security

Testmanagement

Betriebsvorbereitung IT

agil

agil und klassisch gemischt

klassisch

Abb. 2.23 Praxisbeispiel BLS: Hybride Projektorganisation

2.3.9.7

Projektorganisation in Kundenprojekten

Die Projektorganisation in Kundenprojekten muss situativ beurteilt und festgelegt werden.

Verschiedene Konstellationen sind denkbar:

Das Kundenprojekt ist ein Teilprojekt in einem größeren Projekt beim Kunden.

Das Projekt wird gemeinsam durchgeführt. Schlüsselrollen wie beispielsweise die Pro-

jektleitung werden doppelt besetzt. Dies ist beispielsweise in vielen Bauprojekten mit

einem Bauherrenvertreter und einem Bauleiter der Fall.

Das Projekt wird eigenständig umgesetzt. Der Kunde wird in deﬁnierten Teilschritten

für Abnahmen und Reviews involviert.

Wichtig ist, gemeinsam die Rollen zu klären. Wer macht was? Wie grenzen sich die

Aufgaben voneinander ab? Wer trägt für welches Thema die Verantwortung? Weiter emp-

ﬁehlt es sich, gemeinsame Spielregeln festzulegen.

2.3.9.8

Die Anbindung der Projektorganisation an die Stammorganisation

Bei jeder Temporärorganisation stellt sich die Frage, wie sie mit der Gesamtorganisation

verbunden ist. Projektorganisationen sind in drei unterschiedlichen Formen aufgestellt:

120

Methodik

Matrix-Projektorganisation

Die Kompetenzen zwischen Linien und

Projektorganisation sind zu regeln

Projektkoordination

Die Entscheidungskompetenzen

liegen bei den Linieninstanzen

Reine Projektorganisation

Die Entscheidungskompetenzen

liegen bei der Projektleitung

Kompetenzen der Projektleitung

Kompetenzen der Linieninstanzen

gross

klein

gross

klein

Abb. 2.24 Formen der Projektorganisation und Kompetenzzuweisung

Projektkoordination,

reine Projektorganisation und

Matrixorganisation

Die verschiedenen Organisationsformen unterscheiden sich durch die Art und Weise,

wie die Gesamtheit der Führungs- und Entscheidungskompetenz zwischen Linie und Pro-

jekt geteilt wird oder wie groß der Freiheitsgrad des Projektleiters und seines Teams ist.

Details siehe Abb. 2.24.

Ein agiles Projekt kann nur in der reinen Projektorganisation oder in einer Matrix-

Projektorganisation umgesetzt werden.

Die Projektkoordination

Die Projektkoordination (oder Einﬂuss-Organisation) ist die Minimalform einer Projekt-

organisation, bei der die Primärorganisation lediglich um die Stabsstelle des Projektko-

ordinators ergänzt wird. Organigramm siehe Abb. 2.25. Die funktionale Hierarchie bleibt

unverändert bestehen. Der Koordinator (Projektleiter im Stab) besitzt keine Weisungs-

befugnisse. Er ist aber für den sachlichen und terminlichen Ablauf, für die rechtzeitige

2.3

Phase Initialisierung

121

Abteilung A

Abteilung B

Abteilung C

Mitarbeiter A2

Mitarbeiter A3

Mitarbeiter B1

Mitarbeiter B2

Mitarbeiter C1

Mitarbeiter C3

Projektleiter

Organisation

Projekt

Geschäftsleitung

Mitarbeiter A1

Mitarbeiter B3

Mitarbeiter C2

Autorität

Abb. 2.25 Projektkoordination

Information der entsprechenden Linieninstanzen und das richtige Vorgehen verantwort-

lich.

In seiner Koordinationsfunktion schlägt er der Linie Maßnahmen und nächste Ar-

beitsschritte vor. Diese Art von Projektleitung setzt voraus, dass die Linie konstruktiv

zusammenarbeitet und dem Projektleiter die nötigen Informationen zugänglich macht.

Er darf bei dieser Organisationsform nicht allein für die Zielerreichung verantwortlich

gemacht werden, da ihm die Führungsverantwortung im Projekt fehlt und er auf die Be-

reitschaft der Linie besonders angewiesen ist.

Die Vor- und Nachteile der Projektkoordination sind in Tab. 2.19 aufgezeigt.

Die Form der Projektkoordination eignet sich vor allem bei Projekten, die den Rahmen

der herkömmlichen Aufgaben nicht wesentlich übersteigen. Beispiele: Kundenaufträge,

einfache Produktentwicklungen.

Die reine Projektorganisation

Bei dieser Organisationsform wird für das Projekt eine eigenständige neue Organisations-

einheit gebildet. Organigramm siehe Abb. 2.26. Der Projektleiter wie auch die Teammit-

glieder sind vollamtlich im Projekt. Somit trägt der Projektleiter auch die volle Führungs-

verantwortung mit sämtlichen Entscheidungskompetenzen (außer bezüglich der Meilen-

122

Methodik

Tab. 2.19 Vor- und Nachteile der Projektkoordination

Vorteile

Nachteile

Projektkoordination

– hohes Maß an Flexibilität hinsicht-

lich des Personaleinsatzes

– einfacher Erfahrungsaustausch

– große Sammlung an Erfahrungen

über die verschiedenen Projekte

– keine organisatorische Umstellung

– Verantwortung des Projektes bleibt

weitgehend bei der Linie

– niemand fühlt sich für das Pro-

jekt verantwortlich

– geringe Reaktionsgeschwindig-

keit

– organisationsübergreifende

Sichtweise ist erschwert

– kein wirkliches Projektteam

Organisation

Projekt

Abteilung A

Abteilung B

Abteilung C

Mitarbeiter A2

Mitarbeiter A3

Mitarbeiter B1

Mitarbeiter B2

Mitarbeiter C1

Mitarbeiter C3

Projektleiter

Geschäftsleitung

Projektteam

Mitglied 1

Projektteam

Mitglied 2

Projektteam

Mitglied 3

Autorität

Abb. 2.26 Reine Projektorganisation

steinentscheide). Es entsteht ein unabhängiges, efﬁzientes Team/eine Task Force. Diese

Projektorganisation kann recht teuer sein, denn die bisherigen Stellen müssen neu besetzt

werden. Und wenn die Mitarbeiter nicht voll im Projekt ausgelastet sind, entstehen Leer-

zeiten.

Die Vor- und Nachteile der reinen Projektorganisation sind in Tab. 2.20 aufgezeigt.

Die reine Projektorganisation ist von der Linie klar abgegrenzt und hat eine hohe Ei-

genständigkeit. Sie eignet sich . . .

2.3

Phase Initialisierung

123

Tab. 2.20 Vor- und Nachteile der reinen Projektorganisation

Vorteile

Nachteile

Reine Projekt-

organisation

– efﬁziente Organisation für Groß-

projekte

– eindeutige Verantwortung und

Entscheidungskompetenz beim

Projektleiter

– schnelle Reaktion bei Störungen

– hohe Identiﬁkation des Projekt-

teams mit dem Projekt

– unabhängig vom Einﬂuss und

allfälliger Willkür der Linie.

– wenig Personalﬂexibilität, besonders bei

nur zeitweise benötigten Spezialisten

– Rekrutierung und Wiedereingliederung

von Projektmitarbeitern nach Abschluss

des Projektes kann schwierig sein

– Gefahr einer autoritären oder nicht

teamorientierten Führung durch den

Projektleiter eher möglich, da er in einer

speziellen temporären Situation führt.

für Vorhaben, die relativ wenig Berührung zu den herkömmlichen Aufgaben haben

(z. B. eine völlig neue Produktlinie entwickeln, einen Neubau erstellen),

für Projekte mit sehr hohem Risiko (Ausgliederung des Projektes aus dem Unterneh-

men),

bei zeitkritischen Vorhaben, oder

wo eine speziell durchschlagende Wirkung der Ergebnisse nötig ist.

Als Task Force wickelt sie in kurzer Zeit sehr wichtige und dringende Projekte ab.

Die Matrix-Projektorganisation

Diese Organisationsform stellt eine Mischung aus reiner Projektorganisation und Projekt-

koordination dar. Organigramm siehe Abb. 2.27. Die Verantwortungen und Kompetenzen

sind zwischen dem Projektleiter und den Linieninstanzen aufgeteilt. Diese Aufteilung

richtet sich nach dem Projekt und kann in weiten Grenzen variieren. Die Matrix-Pro-

jektorganisation stellt sehr hohe Anforderungen an die klare Aufteilung und Einhaltung

der Abmachungen zwischen der Linie und dem Projekt sowie an das Rollenbewusstsein

aller Beteiligten. Daher ist sie sehr konﬂiktanfällig und erfordert einen hohen Grad an

Kommunikation, vor allem für Regelungen und Vereinbarungen.

Die Vor- und Nachteile der Matrix-Projektorganisation sind in Tab. 2.21 aufgezeigt.

Die Matrix-Projektorganisation ist in der Praxis des klassischen Projektmanagements

die weitaus häuﬁgste Organisationsform. Viele Unternehmen haben mit Rücksicht auf

die begrenzten Ressourcen fast keine andere Wahl. Wegen der Abhängigkeiten und Ge-

gensätze, die aus der hierarchisch orientierten Linienorganisation einerseits und aus der

Teamkultur der Projektorganisation andererseits entstehen, ist dies organisationspsycho-

logisch wohl die heikelste und anspruchsvollste Form. Sie funktioniert nur dann sinnvoll,

wenn:

124

Methodik

Abteilung A

Abteilung B

Abteilung C

Mitarbeiter A2

Mitarbeiter A3

Mitarbeiter B1

Mitarbeiter B2

Mitarbeiter C1

Mitarbeiter C3

Projektleiter

Geschäftsleitung

Projektteam

Mitarbeiter A1

60%

Projektteam

Mitarbeiter C2

20%

Projektteam

Mitarbeiter B3

40%

Mitarbeiter A1

40%

Mitarbeiter B3

60%

Mitarbeiter C2

80%

Autorität

Organisation

Projekt

Abb. 2.27 Matrix-Projektorganisation

Tab. 2.21 Vor- und Nachteile der Matrix-Projektorganisation

Vorteile

Nachteile

Matrix-Projektorga-

nisation

– Projektleiter und Team fühlen sich

verantwortlich für das Projekt

– Eindeutige Verantwortung und

Entscheidungskompetenz beim

Projektleiter

– ﬂexibler Personaleinsatz, keine

Auslastungsprobleme

– Kontinuität der fachlichen Weiter-

bildung, kein Kontaktverlust zur

Linie

– zielgerichtete Koordination ver-

schiedener Interessen

– Förderung der ganzheitlichen, inter-

disziplinären Betrachtung.

– Gefahr von Kompetenzkon-

ﬂikten zwischen Linien- und

Projektautorität

– Verunsicherung von Führungs-

kräften wegen Verzicht auf

Ausschließlichkeit

– Verunsicherung von Mitarbeitern

als „Diener zweier Herren“

– hohe Anforderungen an die

Informations- und Kommuni-

kationsbereitschaft

2.3

Phase Initialisierung

125

die Aufgaben und Kompetenzen klar geregelt sind, analog einer Vortrittsregelung bei

Kreuzungen,

die Linie mittels Kapazitätsplanung die Ressourceneinsätze des Mitarbeiters in der Li-

nienarbeit und in der Projektmitarbeit optimal koordiniert,

Probleme und Konﬂikte thematisiert und auf der richtigen Hierarchiestufe ausdiskutiert

werden, d. h., wenn die Konﬂiktkultur genügend ausgeprägt ist; ist dies nicht der Fall,

werden die Konﬂikte ins System delegiert,

die Unternehmensbereiche zusammenarbeiten wollen und sich nicht über das Projekt

konkurrieren.

2.3.9.9

Die Kompetenzregelung

RACI Matrix

Viele Konﬂikte und Missverständnisse entspringen unklaren oder unterschiedlich verstan-

denen Verantwortlichkeiten. Die RACI Matrix ist eine Methode, um die Verantwortlich-

keiten vollständig und ohne Überschneidungen zu erfassen und in Form einer Tabelle zu

visualisieren. In den Zeilen werden alle Aufgaben/Aufträge aufgelistet, in einem Projekt

beispielsweise die Lieferobjekte oder Arbeitspakete. In den Spalten werden alle Leis-

tungsträger aufgelistet, im Projekt beispielsweise die unterschiedlichen Rollen.

Die RACI Matrix beantwortet für ein Projekt folgende drei Fragen:

Welche Arbeitspakete sind zu erledigen?

Welche Rollen sind beteiligt?

Wer ist wofür verantwortlich?

In den Feldern werden die vier Verantwortlichkeiten R, A, C und I gemäß Tab. 2.22

eingetragen.

Tab. 2.22 RACI Verantwortlichkeiten

RACI Code

RACI Verantwortlichkeit

Responsible

Verantwortlich im Sinne der Durchführungsverantwortung. Die Person

führt das Arbeitspaket selber durch oder delegiert es.

Accountable

Rechenschaftspﬂichtig, entscheidungsbefugt, übergeordnet verantwort-

lich im Sinne von „genehmigen“, „billigen“ oder „unterschreiben“. Die

Person trägt die rechtliche oder kaufmännische Verantwortung.

Consulted

Konsultativ beizuziehen. Die Person, die vielleicht nicht direkt an der

Umsetzung beteiligt ist, aber relevante Informationen für die Umsetzung

hat und deshalb befragt werden soll oder muss

Informed

Zu informieren. Die Person, die Informationen über den Verlauf bzw. das

Ergebnis der Tätigkeit erhält oder die Berechtigung besitzt, Auskunft zu

erhalten.

126

Methodik

Tab. 2.23 Beispiel einer RACI Matrix

Auftrag-

geber

Projekt-

ausschuss

Projekt-

leiter

TP Tech-

nik

TP Pro-

duktion

TP Mar-

keting

Arbeitspakete

1 Entwicklungsversuche

2 Entwurf Prototyp

3 Prototyp herstellen

4 Vorabklärung

Produktion

5 Beratung Konstruktion

6 AVOR

7 Werbekonzept

8 Servicekonzept

9 Wirtschaftlichkeit

Tab. 2.23 zeigt ein Beispiel einer RACI Matrix.

Die RACI Matrix kann nun wie folgt überprüft und analysiert werden.

Im Rahmen der horizontalen RACI Analyse werden folgende Punkte überprüft:

In jeder Zeile soll ein R stehen. Bei mehreren R in einer Zeile ist zu prüfen, ob das

Arbeitspaket weiter unterteilt werden kann. Zumindest stimmen sich in diesem Fall die

Verantwortlichen eng ab.

In jeder Zeile soll genau ein A stehen. Die übergeordnete Verantwortlichkeit kann nicht

geteilt werden.

Bei einer hohen Anzahl C oder I ist zu prüfen, ob dies noch zielführend ist bzw. wie

hoch der zu erwartende Nutzen dieser konsultativen bzw. informativen Einbindung ist.

Im Rahmen der vertikalen RACI Analyse werden folgende Punkte überprüft:

Wenn einer Rolle eine hohe Anzahl R zugeteilt ist, prüfe man, ob die Person alle Ar-

beitspakete termingerecht erfüllen kann.

Ist einer Rolle eine hohe Anzahl A zugeteilt, prüfe man, ob die Rechenschaftspﬂicht

an andere Stellen delegiert werden kann.

Hat eine Rolle kaum leere Felder, ist zu hinterfragen, ob diese Person in alle Arbeits-

pakete eingebunden werden muss.

Ein Gesamtüberblick ermöglicht die Plausibilisierung, ob grundsätzlich die Arbeitspa-

kete sinnvoll und ausgewogen den Fähigkeiten und Stärken der entsprechenden Perso-

nen zugewiesen sind.

Die RACI Matrix eignet sich sehr gut zum Auﬂösen von Konﬂiktsituationen, deren

Ursache in unscharfen oder ungeklärten Rollendeﬁnitionen liegt. In größeren Projektum-

gebungen können – getreu dem Motto „Viele Wege führen nach Rom“ – einzelne Arbeits-

pakete verschiedenen Rollen zugewiesen werden. Dabei ist es wenig relevant, welcher

2.3

Phase Initialisierung

127

Rolle ein Arbeitspaket zugewiesen ist. Von größter Wichtigkeit ist hingegen, dass alle Be-

teiligten sich bewusst sind, welche Rolle die entsprechende Verantwortung trägt und dass

jede Rolle gelebt und respektiert wird. Eine ähnliche Darstellung der Kompetenzregelung

ist das Funktionendiagramm.

Führungskontinuum bei wechselnder Verantwortung

Unternehmen gestalten ihre Aufbau- und Ablauforganisationen meist arbeitsteilig. Auf-

gaben werden dadurch üblicherweise in Organisationseinheiten erledigt. Die Abwicklung

von Projekten verläuft dann oft durch zwei (oder mehrere) organisatorische Einheiten,

wie Abb. 2.28 zeigt. Erschwerend kann hinzukommen, dass nicht alle Einheiten ihre

Arbeiten als Projekt bezeichnen. Beispielsweise bezeichnet ein Account Manager seine

Akquisitionstätigkeit kaum als Beauftragungs- und Initialisierungsphase eines Projekts,

obwohl ein eigentlicher Projektleiter den Auftrag dann weiterführt. Der Projektleiter an-

dererseits übernimmt ein Projekt, bei dem beispielsweise der Ablieferungstermin und die

Produktkosten vertraglich deﬁniert sind, obwohl die Anforderungen auf ihre Machbarkeit

innerhalb der Termin- und Budgetvorgaben nicht überprüft wurden. Der Projekterfolg ist

Anfrage

Offerte

Auftrag

Entwicklung

Übergabe

Projektleitung – Aquisition

Projektdauer

Projektleitung – Realisation

Produktion

Abnahme

Abb. 2.28 Punktuelle Projektübergabe vs. Führungskontinuum am Beispiel eines Auftragsabwick-

lungsprojektes

128

Methodik

dadurch in hohem Maß gefährdet, pauschale Schuldzuweisungen sind sehr wahrschein-

lich.

Beispiele möglicher Kombinationen sind:

Verkauf ! Auftragsabwicklungsprojekt

Produktmanagement ! Entwicklungsprojekt

Entwicklungsprojekt ! Industrialisierung zur Produktionsaufnahme

Produktion ! Support/After Sale Service

Aus Projektsicht handelt es sich hierbei um ein Projekt mit wechselnder Projektleitung

und oft auch wechselndem Projektteam. Um hier ein Führungskontinuum sicherzustellen,

bewähren sich in der Praxis folgende Schritte:

Neben einem sauberen Handover zwischen den beiden Projektleitungsverantwortlichen

– z. B. als „Account Manager“ und „Projektleiter“ bezeichnet – soll der vorgesehene

zukünftige Projektleiter bereits zu Beginn der Aktivitäten des Account Managers punk-

tuell zu Kundengesprächen oder internen Besprechungen beigezogen werden. So kann

er sich bereits ein Bild machen, was auf ihn zukommen wird. Auch kann er Erfahrun-

gen aus früheren Projekten einbringen. So kann er beispielsweise sicherstellen, dass

Toleranzen, welche an die Grenze des eigenen Produktionsverfahrens gehen, vor Be-

ginn des Projekts mit dem Kunden festgelegt werden.

Ebenso soll der Account Manager beim Schluss-Review und den Lessons Learned des

Projekts wieder teilnehmen. Hier erhält er für zukünftige Aufträge wichtige Hinweise,

welche Details die Marge erhöhen oder aber erodieren.

Durch diese mehrmalige Verzahnung der beteiligten Projektleitungsverantwortlichen

erhöht sich die Wahrscheinlichkeit, dass das Gesamtprojekt erfolgreich abgeschlossen

werden kann. Ein solches Vorgehen ist bei der zunehmenden Projektkomplexität hilfreich.

2.3.9.10

Bildung der Projektorganisation

Im Allgemeinen werden Projektorganisationen zu unkritisch und zu unsorgfältig zusam-

mengestellt. Gründe dazu sind oftmals

eine einseitige Optik (z. B. nur aus der Perspektive des Auftraggebers, der Fachabtei-

lung usw.),

eine Kultur des ständigen Auswechselns von Personal,

Angst vor heiklen und konﬂiktträchtigen Diskussionen über die personelle Zusam-

mensetzung des Teams (Engagement, Interessen, Verfügbarkeit, Know-how, Sympa-

thie/Antipathie) und

die Verfügbarkeit von Personen.

Folgende Tipps für die Bildung der Projektorganisation haben sich in der Praxis be-

währt:

2.3

Phase Initialisierung

129

Bei Projekten mit stark divergierenden Interessen wird der Mitwirkungsgrad der An-

spruchsgruppen größer und damit die Projektorganisation umfangreicher sein. Trotz-

dem ist es ratsam die Projektorganisation möglichst schlank zu halten. Eine breite

Beteiligung kann auch mit Begleitgruppen, speziellen Workshops für Betroffene und

Benutzer – evtl. mit einer Großgruppenveranstaltung – erreicht werden.

Auf deﬁnierte Rollen achten, Mehrfachrollen vermeiden! Gewaltentrennung zwi-

schen den Gremien anstreben.

Die Nominierung der Projektmitglieder nicht dem Zufall überlassen. Neben der Nomi-

nierung der Teilnehmer für die Gremien auch festlegen, wie Führungskräfte, Auftrag-

geber oder Projektleiter nominieren sollen, um eine breite Abstützung der Anspruchs-

gruppen zu erreichen.

Projektmitarbeiter sollen über die notwendigen Ressourcen verfügen. Überlastete

Projektmitglieder sind nicht motiviert oder sehen sich gezwungen, ihre Prioritäten

selber je nach Interesse festzulegen.

Im Laufe des Projektes kann sich die Projektorganisation von Phase zu Phase ändern.

Innerhalb einer Phase sollte die Organisation möglichst konstant gehalten werden, um

die Teamprozesse nicht zu unterbrechen.

Lieber weniger Projekte mit fachlich hervorragenden und motivierten Personen. Auch

das Management muss sich im Projekt engagieren können!

2.3.10

Informationsbeschaffung und Situationsanalyse

Einer der Schwerpunkte in der Initialisierungsphase ist die kritische Auseinandersetzung

mit dem wirklichen Projektziel. Dieses kann sich in mehrfacher Hinsicht von den vorder-

gründigen Zielen unterscheiden:

Der Projektauftrag, die Rahmenbedingungen oder die Zielsetzungen sind unklar

und/oder unvollständig.

Der Auftraggeber kann aus seiner Wahrnehmung heraus eine unvollständige Zielvor-

gabe gemacht haben.

Interessenkonﬂikte und Machtverhältnisse zwischen verschiedenen Stakeholdern kön-

nen zu einer unscharfen Zielvorgabe geführt haben.

Der Projektauftrag bedarf zuerst der Identiﬁkation und Analyse eines Symptoms. Erst

mit den Ergebnissen der Analyse kann die eigentliche Zielformulierung erfolgen. Bei-

spiel: „Seit drei Monaten erhalten wir erhöhte Mengen an Rückläufern vom Markt.

Finden Sie das Problem und beheben Sie die Ursache!“

In der Projektarbeit ist meistens nicht alles von Anfang an klar. Deshalb lohnt es sich,

zuerst in den Fact Finding Modus zu schalten, eine Situationsanalyse vorzunehmen und

Informationen zu beschaffen.

130

Methodik

Tab. 2.24 Elemente der Situationsanalyse

Auftragsklärung

folgende Fragen klären:

– Was ist der Anlass, etwas zu tun?

– Worum geht es wirklich?

– Ist der Projektauftrag vollständig?

– Haben Auftraggeber und Projektteam das gleiche Verständnis vom

Auftrag? (Siehe Abschn. 2.3.12)

Analyse der Gegenwart

– Kontextanalyse

– Stakeholder-Analyse, siehe Abschn. 2.3.5

– SWOT-Analyse

– Ursachen-Wirkungsanalyse

– Analyse der Rechtsgrundlagen und Compliance Vorgaben

– Schutzbedarfsanalyse

Einbezug der Zukunft

– Planhorizont

– Szenario-Technik

Die Situationsanalyse dient der Klärung der Problemsituation, des relevanten Problem-

umfeldes im Sinne einer Auftragsklärung und Lagebeurteilung und der Eingrenzung des

Problems. Sie wird bei jedem Meilenstein überprüft und kann für Teilaspekte nach Be-

darf wiederholt oder ergänzt werden. Je nach Problemstellung und vorhandenem Wissen

kann eine Situationsanalyse in wenigen Stunden „ad hoc“ durchgeführt werden, oder sie

braucht detaillierte Abklärungen durch mehrere Personen, möglicherweise über Monate

hinweg. Dies ist typisch bei Produktentwicklungs- und Anlageprojekten mit der Gefahr,

die Analyse bis zur Paralyse zu treiben.

Eine vollständige Situationsanalyse beinhaltet zumindest die Aspekte gemäß Tab. 2.24.

2.3.10.1

Kontextanalyse

In der Praxis wird in zwei unterschiedlichen Fällen von Kontextanalyse gesprochen:

Umfeld- oder Umweltanalyse

Methode zur Erfassung der Aufgaben von Nutzern.

Die Umfeld- und Umweltanalyse hat eine gewisse Übereinstimmung mit der Stakehol-

der-Analyse. Es sind folgende drei Betrachtungswinkel von Relevanz:

zeitlich: Was geschah vor dem Projekt? Wie sah die Welt vor dem Projekt aus? Was

soll nach der Beendigung des Projekts passieren? Wie sieht die Welt nach dem Projekt

aus?

sachlich: Welche sachlichen Einﬂussfaktoren, Rahmenbedingungen und Trends sind

für das Projekt von Bedeutung?

sozial: Welche Personen und/oder Personengruppen haben ein Interesse am Projekt?

Wer beeinﬂusst das Projekt oder wird vom Projekt tangiert? Siehe Stakeholder-Analyse

Abschn. 2.3.5

2.3

Phase Initialisierung

131

Bei der Methode zur Erfassung der Aufgaben von Nutzern werden neben den Aufgaben

auch die Prozesse der Nutzer analysiert. Dabei sind folgende Fragestellungen genauer zu

untersuchen:

Wo erfüllen die Nutzer ihre Aufgaben?

Unter welchen Umständen? Was tun sie?

Wie erfüllen sie ihre Aufgaben?

Warum machen sie es auf diese Weise?

2.3.10.2

SWOT-Analyse

Die SWOT-Analyse identiﬁziert Strengths (Stärken), Weaknesses (Schwächen), Oppor-

tunities (Chancen) und Threats (Gefahren) des betrachteten Systems (Unternehmen oder

Projekt). Die SWOT-Analyse prüft sowohl die interne als auch externe Umgebung. Stär-

ken und Schwächen sind kontrollierbare interne Faktoren in der Gegenwart und können

bei Bedarf und entsprechendem Willen verändert werden. Chancen und Gefahren sind

wenig bis nicht kontrollierbare externe Faktoren in der Zukunft und können nicht von

der Organisation beeinﬂusst werden. Die Organisation kann darauf aber entsprechende

Maßnahmen ergreifen, um ihnen geeignet zu begegnen.

Eine SWOT-Analyse kann auf unterschiedlichen Flughöhen und für verschiedenen

Umfang erstellt werden: Eine Organisation kann als Ganzes betrachtet werden. Auch

einzelne Themenbereiche, Leistungsangebote, das durchzuführende Projekt oder einzelne

Abteilungen können einer SWOT-Analyse unterzogen werden. Tab. 2.25 zeigt auf, wie

Tab. 2.25 Fragen für die SWOT-Analyse

Strengths

(Stärken)

– Was läuft gut?

– Worauf können wir uns verlassen?

– Was stellt uns zufrieden?

– Woher beziehen wir Energie?

– Worauf sind wir stolz?

– Was sind unsere Stärken?

Weaknesses

(Schwächen)

– Was ist schwierig?

– Welche Störungen behindern uns?

– Was fehlt uns?

– Was fällt uns schwer?

– Wo liegen unsere Fallen?

Opportunities

(Chancen)

– Welche Möglichkeiten eröffnen sich uns?

– Welche Marktsegmente werden boomen?

– Was können wir im Umfeld nutzen?

– Was liegt brach?

– Was ist ausbaubar?

Threats

(Gefahren)

– Wo lauern die Gefahren?

– Welche Schwierigkeiten kommen auf uns zu?

– Womit müssen wir rechnen?

– Was sind unsere Befürchtungen?

132

Methodik

Tab. 2.26 Strengths (Stärken), Weaknesses (Schwächen), Opportunities (Chancen) und Threats

(Gefahren) und der Umgang damit

SWOT

Positiv

Negativ

– Interne Aspekte

– Heutige Situation

– beeinﬂussbar

Strengths (Stärken)

! Beibehalten oder ausbauen

Weaknesses (Schwächen)

! Eliminieren oder vermin-

dern

– Externe Einﬂüsse und Trends

– Zukünftige Situation

– Kaum beeinﬂussbar

Opportunities (Chancen)

! Nutzen oder ausbauen

Threats (Gefahren)

! Bewerten und Alternativen

entwickeln

Tab. 2.27 Fragen zur Konkretisierung der SWOT-Strategien

S-O Strategie

Welche Opportunities (Chancen) können mit den aktuellen Strengths (Stärken)

genutzt werden?

S-T Strategie

Welche Threats (Gefahren) können mit unseren aktuellen Strengths (Stärken),

eliminiert oder vermindert werden?

W-O Strategie

Welche Opportunities (Chancen) könnten genutzt werden, wenn unsere aktuel-

le Weakness (Schwäche) eliminiert würde?

W-T Strategie

Welche Threats (Gefahren) könnten gebannt werden, wenn wir unsere aktuelle

Weakness (Schwäche) eliminieren würden?

die einzelnen Themen analysiert und welche Fragen an die Mitglieder einer Organisation

gestellt werden können.

Mit den Stärken, Schwächen, Chancen und Gefahren ist unterschiedlich umzugehen,

wie dies Tab. 2.26 zeigt.

Ein Unternehmen oder Projekt kann nur seine Stärken und Schwächen bearbeiten und

beeinﬂussen und damit auf die Chancen und Gefahren des Marktes reagieren.

In der Praxis zeigt sich, dass die Nennung und Unterscheidung von Stärken und Schwä-

chen eher einfach gelingt, es vielen Teams aber schwerfällt, Chancen und Gefahren zu

identiﬁzieren und die obere und untere Hälfte vermischt werden: Oft werden Stärken als

Chancen bzw. Schwächen als Gefahren bezeichnet.

Die SWOT-Strategien gemäß Abb. 2.29 sind möglich.

Abgeleitet aus den SWOT-Strategien stellen sich die Fragen, wie in Tab. 2.27 aufge-

zeigt, um die Strategien zu konkretisieren.

2.3.10.3

Ursachen-Wirkungsanalyse

Eine systematische Methode, welche erlaubt, komplexe Ursachen-Wirkungszusammen-

hänge darzustellen, wurde schon in den 1950er Jahren vom Japaner Kaoru Ishikawa ent-

wickelt. Es handelt sich um eine einfache Technik zur systematischen Ermittlung von

Problemursachen. Das Problem wird am Kopf eines Fischgrats notiert. Die Hauptursa-

chen, welche wie Fischgräten als Pfeile auf die „Wirbelsäule“ zeigen, können für viele

Situationen immer wieder verwendet werden: Mensch, Methode, Maschine, Material,

Milieu, Messung und Management. Auf diese Hauptpfeile zielen nun wiederum Pfeile,

welche mögliche Nebenursachen darstellen können (Abb. 2.30).

2.3

Phase Initialisierung

133

Strengths

Weaknesses

Opportunities

Threats

S-T

Strategie

W-O

Strategie

S-O

Strategie

W-T

Strategie

Abb. 2.29 SWOT-Strategien

Die Erstellung eines Ishikawa-Diagramms erfolgt in einer moderierten Arbeitsgruppe.

Für den Erfolg der Methode ist es wichtig, dass für jeden betroffenen Bereich des zu

analysierenden Problems sachkundige Teilnehmer anwesend sind. Dies kann bedeuten,

dass auch externe Personen (z. B. Lieferanten, Kunden) hinzugezogen werden müssen.

Die Mitglieder des Teams notieren sich auf einem großen Papier (Pinnwand, Flip-

chart) möglichst klar und verständlich das Problem, bis alle mit der Problemformulierung

einverstanden sind. Die Einzelergebnisse der Ursachenforschung werden mit einem Brain-

storming auf Karten notiert. Diese Karten werden dann gemäß „Bauplan“ zum Ishikawa-

Diagramm aufgereiht. Im Wechsel der schrägen und horizontalen Pfeile kann nach immer

tieferen Ursachen geforscht werden.

Das Ishikawa-Diagramm kann auch verwendet werden, um Aktivitäten in Prozessen

zu strukturieren bzw. Prozesse zu analysieren. In diesem Fall steht an der Spitze des

Hauptpfeils das Ergebnis des Prozesses, während die einzelnen Zweige die Aktivitäten

hierarchisch geordnet darstellen.

Mit der Dispersionsmethode werden einzelne Ursachen einer Hauptursache zugeord-

net. Jede einzelne Ursache wird hinterfragt: „Warum tritt diese Ursache (Dispersion) auf?“

Es wird so lange hinterfragt, bis dem Team keine Ursachen mehr einfallen. Als Faustregel

134

Methodik

Maschinen

(Ursache

1. Ordnung)

Methoden

(Ursache

1. Ordnung)

Material

(Ursache

1. Ordnung)

Milieu

(Ursache

1. Ordnung)

Management

(Ursache

1. Ordnung)

Menschen

(Ursache

1. Ordnung)

Prozessachse

kühlt zu

rasch ab

(Ursache

2. Ordnung)

Ursachen

nach

Ordnung

Zu viel

«Ausschuss»

(Konkret

formulierte

Wirkung)

Abb. 2.30 Ursachen-Wirkungsanalyse

gilt hierbei die Technik der „Fünf Warum“: Bis zu fünfmal „Warum?“ fragen, um an die

Wurzel des Problems zu gelangen.

Mögliche Fragestellungen sind: „Was verursacht die Wirkung . . . ? Weshalb passier-

te . . . ? Wie würde es sich verhalten, wenn sich dieser Aspekt verändert? Wer ist vom

Problem betroffen? Wie erleben Sie . . . ? Wer leidet unter dieser Situation, diesem Zu-

stand?“

2.3.10.4

Analyse der Rechtsgrundlagen und Compliance Vorgaben

Die Umsetzung von Projekten erfordert eine genaue Kenntnis der unterschiedlichen Ge-

setze und regulatorischen oder ﬁrmeninternen Vorgaben. Die Gesetze und Vorgaben kön-

nen die Suche nach Lösungskonzepten einschränken (beispielsweise Einhaltung von Um-

weltauﬂagen) oder die Abwicklung des Projektes stark beeinﬂussen (beispielsweise Ein-

haltung der Wochenhöchstarbeitszeiten der Projektmitarbeiter).

Daher gilt es, die für das Projekt relevanten Themen, in den folgenden Bereichen zu

identiﬁzieren und zu analysieren:

Rechtsvorschriften (Gesetze, Verordnungen)

Compliance und Governance-Vorgaben

2.3

Phase Initialisierung

135

Vorschriften für Sicherheit, Gesundheit und Umweltschutz (SGU)

Verhaltensregeln und Berufsvorschriften

Prinzipien und Ziele der Nachhaltigkeit

Standards und Normen

Nach der Analyse sind die Auswirkungen und Konsequenzen für das Projekt zu beur-

teilen und abzuleiten. Während der Umsetzung des Projektes ist dafür zu sorgen, dass die

identiﬁzierten und relevanten Rahmenbedingungen eingehalten werden.

2.3.10.5

Schutzbedarfsanalyse

Cyberattacken und Hackerangriffe stellen täglich eine Bedrohung dar. Informationssicher-

heit und Datenschutz sind nicht nur in ICT-Projekten wichtige Themen. Die Schutzbe-

darfsanalyse ermittelt den Schutzbedarf für Daten, Dokumente und ICT-Anwendungen.

Die betrachteten Schutzziele sind Integrität, Vertraulichkeit und Authentizität. Analysiert

werden Geschäftsprozesse, ICT-Anwendungen, ICT-Systeme, Daten, Dokumente, ICT-

Infrastruktur, Zugang zu Gebäuden und Räumen, aber auch Zulieferer und Lieferanten.

Die gewonnenen Erkenntnisse müssen in der Umsetzung des Projektes und in der Kon-

zeption der Lösung berücksichtigt werden. Die gewonnenen Erkenntnisse können den Lö-

sungsgestaltungsraum einschränken. Mögliche Maßnahmen zum Schutz der Vertraulich-

keit und Integrität können beispielsweise Verschlüsselung der Daten bei der Speicherung

oder ein Berechtigungssystem für den Zugriff auf Anwendungen oder Daten sein. Die

gewonnenen Erkenntnisse können auch in die Risikoanalyse einﬂießen (Abschn. 2.3.8).

2.3.10.6

Planhorizont

Ein verändertes Umfeld kann die Projektziele und den späteren Nutzen eines Produktes

bedeutsam beeinﬂussen: Je ausgeprägter die Einﬂussfaktoren sich ändern, umso größer

ist die Wirkung auf das Projekt, und je größer die Zeiträume, umso ausgeprägter kann

die Veränderung sein. Der Zielﬁndungsprozess muss deshalb auf den Planungshorizont

ausgerichtet sein, wie Abb. 2.31 zeigt.

2.3.10.7

Szenario-Technik

Szenarien sind alternative Bilder der Zukunft und helfen, mögliche Projektverläufe früh-

zeitig zu erkennen und in ihren Auswirkungen abzuschätzen. Die Szenario-Technik hilft

insbesondere in Situationen, die im Eintretensfall große Konsequenzen haben und nur

kurze Reaktionszeiten erlauben.

Mit Szenario-Techniken werden „Wenn-Dann-Optionen“ entwickelt und vorbereitet.

Untersucht werden sowohl die Auswirkungsstärke einzelner Maßnahmen auf die eigene

Organisation als auch die Prognosesicherheit in der Vorhersage dieser Maßnahmen. Je

höher eine zu erwartende Aktion bezüglich beider Dimensionen tendiert, desto mehr Auf-

merksamkeit ist notwendig, da Reaktionszeit und Kosten bzw. Investitionen eine enorme

Rolle spielen. Wenn die Unsicherheit sich auf zwei Alternativen mit stark unterschiedli-

chem Aufwand reduziert, werden beide Szenarien planerisch als Alternativen erfasst.

136

Methodik

Umfeld bei

Projektende

Umfeld

heute

Umfeld bei

Planhorizont

Projektaufgaben

bei Projektbeginn

Produkt

bei Planhorizont

Mitbestimmend

für die erfolgreiche

Nutzung des

Projektproduktes

Mitbestimmend bei

der Lösungssuche

Mitbestimmend

für die erfolgreiche

Einführung des

Projektproduktes

Produkt bei

Projektende

Abb. 2.31 Berücksichtigung von Faktoren mit Einﬂuss auf die Zukunft

Stellen Sie sich vor, ein Kunde wünscht eine hochpräzise Maschine, die Sie noch nie

zuvor mit einer solch geringen Toleranz produziert haben. Ihre Ingenieure haben in einer

Machbarkeitsanalyse festgestellt, dass Sie die geforderte Präzision mit Ihren heutigen Pro-

duktionsmethoden und etwas Zusatzarbeit „mit etwas Glück“ schaffen könnten. Wie viel

Zusatzarbeit nötig sein wird, lässt sich nicht von vornerein abschätzen. Wenn sich heraus-

stellt, dass das Ziel mit den Ihnen bekannten Methoden nicht erreichbar ist, muss ein neues

Verfahren mit einem Aufwand von acht Personenmonaten erarbeitet werden. Zudem muss

dann ein Reinraum für das neue Verfahren bezogen werden, was Investitionen in Höhe von

C 600k bedingt. Beide Szenarien werden eingeplant. Ein Meilenstein wird gesetzt, wann

spätestens zu entscheiden ist, die erste Alternative nicht mehr weiterzuführen (Deadline).

Unter Umständen entscheidet sich die Projektleitung auch dafür, beide Varianten parallel

umzusetzen. Falls das bestehende Verfahren sich nach z. B. drei Monaten als untauglich

erweist, ist das neue Verfahren nur fünf Monate später einsatzbereit. Der Preis für diese

Beschleunigung sind die Kosten und gebundenen Ressourcen für das zweite Team und

allfällige Investitionen in erste Reinraumkomponenten.

2.3

Phase Initialisierung

137

2.3.11

Projektstrukturierung

Die Planung und damit auch die Strukturierung von Projekten wird je nach Situation sehr

unterschiedlich ausgeführt. Bei ausgeprägten Standardprojekten mit großer Erfahrung im

Unternehmen wird die Struktur bereits in Vorgabedokumenten bereitgestellt und zwecks

einheitlichem Vorgehen auch durchgesetzt. In kleineren Projekten oder Potenzialprojekten

mit hoher Zieloffenheit, z. B. bei Grundlagenforschung oder wenn die detaillierten Spe-

ziﬁkationen noch nicht verbindlich festgelegt wurden, werden lediglich Basisstrukturen

gesetzt, z. B. verschiedene Teams zusammengestellt.

Bei der Projektstrukturierung – auch Grobplanung genannt – geht es darum, Projekte

je nach ihrer Größe und Komplexität übersichtlich zu strukturieren und sie damit über-

haupt beherrschbar zu machen. Dabei wird das Projekt, wie in Abb. 2.32 gezeigt, in zwei

Dimensionen strukturiert:

Phasengliederung durch Setzen von Meilensteinen zwischen den Phasen ! Meilen-

steinplan

Zerlegen des Projekts in fassbare und abgrenzbare Bausteine ! Teilprojekte und Pro-

jektstrukturplan

Konzepte

Pﬂichtenheft

Ziele

Lastenheft

Projektstrukturierung

Abb. 2.32 Projektstrukturierung

138

Methodik

Die Phasengliederung mit dem Meilensteinplan ist eine zeitliche Gliederung des Pro-

jekts. Üblicherweise wird eine Projektphase abgeschlossen, bevor die nächste Phase bear-

beitet wird.

Teilprojekte unterteilen ein umfangreiches und komplexes Projekt in mehrere Teile,

welche pro Abteilung oder pro Subsystem gegliedert werden können. Pro Teilprojekt wird

ein Teilprojektleiter benannt.

Der Projektstrukturplan ist eine bausteinorientierte Strukturierung des Projekts und

hilft, das Projekt in überblickbare Ergebnisse, Lieferobjekte und Arbeitspakete zu unter-

teilen.

2.3.11.1

Vorgehen bei der Projektstrukturierung:

Projektphasen und Meilensteine festlegen

Entscheide festlegen, die bei den Meilensteinen zu treffen sind

Große Projekte falls nötig in Teilprojekte aufteilen: Teilprojekte abgrenzen und Teil-

projektleiter bestimmen, erste Absprachen durchführen

Lieferobjekte und Arbeitspakete deﬁnieren und abgrenzen: Struktur der Lieferobjekte

und Arbeitspakete festlegen und die Verantwortung zuteilen. Die Summe aller Arbeits-

pakete bildet den Projektstrukturplan.

Das Resultat wird im Meilensteinplan und im Projektstrukturplan dokumentiert. Teil-

projekte werden im Organigramm dokumentiert.

2.3.11.2

Im Projekt Meilensteine setzen: der Phasenplan

Der Phasenplan (auch Meilensteinplan genannt), wie in Abb. 2.33 gezeigt, stellt den zeit-

lichen Ablauf des Projektes grob dar und soll die folgenden Fragen klären:

In welche Phasen soll das Projekt zeitlich aufgeteilt werden?

Welche Etappenziele, Dokumente und Resultate müssen bei den Meilensteinen zwi-

schen den Phasen erreicht sein und überprüft werden?

Design Phase

Study Phase

Utilisation Phase

System Integrations

Review Design

Goals

Review

Design Input

Review Design

Output

(Design Freeze)

System

Release

System Design

Freeze

Review User

Requirements Specifications

Market

Release

Ideas

System / Project

Level

Review

Project Idea

Development Phase

Pre Pro-

ducon

Review

Design Transfer

Series

Producon

Sub-Project

Level

Abb. 2.33 Praxisbeispiel Metrohm: Meilensteinplan

2.3

Phase Initialisierung

139

Welche Lieferobjekte und Arbeitspakete werden in welcher Phase bearbeitet?

Bei welchem Meilenstein ist ein Review notwendig?

Nach welchen Kriterien wird ein Projekt in Phasen aufgeteilt?

Es wäre riskant, ein großes Vorhaben in einem Zug durchzuführen und erst am Schluss

zu überprüfen, ob das beabsichtigte Ziel erreicht wurde. Darum unterteilt man große Pro-

jekte in einzelne Phasen mit überprüfbaren Zwischenresultaten, den Etappenzielen. Der

Projektleiter überlegt sich, welche Arbeiten in welcher Phase durchgeführt werden müs-

sen oder wofür in welcher Phase ein Konzept zu erstellen ist, über das beim Meilenstein

entschieden wird.

Weiter ist es notwendig, ein Projekt oder eine Projektphase weiter zu unterteilen, wenn

das spätere Entdecken eines Fehlers, einer falschen Marschrichtung oder ungenügender

Akzeptanz zu unverhältnismäßig großen Konsequenzen führen würde. Dann ist es sinn-

voll, mit einem weiteren Meilenstein einen geplanten Zeitpunkt festzulegen, an dem das

Erreichte überprüft und das weitere Vorgehen festgelegt wird.

Bei einem kleinen, unproblematischen Projekt mit hohem Routinefaktor genügen viel-

leicht zwei Phasen: eine Initialisierungs- und Konzeptphase sowie eine Realisierungspha-

se. Bei größeren Projekten oder größerer Unsicherheit im Projekt sind mehr Phasen und

Meilensteine an den kritischen Zeitpunkten sinnvoll. Abb. 2.34 zeigt Meilensteinpläne für

einfache und komplexe Projekte.

Wann ist ein Review notwendig?

Wenn nach einem Meilenstein das weitere Vorgehen speziell große Konsequenzen auslö-

sen kann, Risiken ﬁnanzieller Art eingegangen werden oder das Firmenimage betroffen

sein kann, oder wenn das Team Neuland beschreitet mit entsprechend größerer Unsicher-

heit, immer dann ist es unternehmerisch sinnvoll, die Meilensteinüberprüfung besonders

sorgfältig und kritisch durchzuführen. Dann wendet der Projektleiter ein etabliertes Ver-

fahren an und führt ein Review (kritische Überprüfung) durch.

Der Zweck des Reviews ist, den erreichten Zwischenstand und das weitere Vorgehen

kritisch zu überprüfen, auch aus anderer, unabhängiger Sicht. Damit soll sichergestellt

werden, dass der Reifegrad der erarbeiteten Dokumente und der Entscheidungsgrundla-

gen angemessen ist, um die nächste Phase auszulösen. Eventuelle Fehler, die sich später

auswirken würden, sollen noch rechtzeitig erkannt werden. Mögliche Themen des Re-

views sind:

Sind neue Risiken identiﬁziert oder bestehende neu zu qualiﬁzieren?

Stimmen die früheren Annahmen noch?

Treffen die Rahmenbedingungen noch zu?

Ist das gewählte Vorgehen noch sinnvoll?

140

Methodik

Machbarkeitsstudie

Integration/Test

Lastenheft WAS

Nullserie

Grobkonzept WIE

Seriebereinigung

Detailkonzepte

Realisation

Deﬁnitions- und

Konzeptphase

Realisationsphase

Beauftragung

Initialisierung

Konzept

Realisation

Einführung

Meilenstein

Abb. 2.34 Meilensteinpläne für einfache und komplexere Projekte

Häuﬁg verlangt der Auftraggeber eine solche kritische Überprüfung, bevor er die Frei-

gabe der nächsten Phase unterschreibt und damit die erforderlichen Mittel freigibt. Pro-

jektleiter und Auftraggeber sprechen sich ab, wo ein Review notwendig ist.

In gewissen Unternehmen mit Standardprojektprozessen können das Review und der

Zeitpunkt dieses Reviews vorgegeben sein. Für diese Aktivität werden Begriffe wie Qua-

lity Gates oder Meilensteinreview verwendet.

2.3.11.3

Projekte, Teilprojekte, Arbeitspakete, Lieferobjekte und Tätigkeiten

Innerhalb und zwischen dem Gesamtprojekt, den Teilprojekten, den Arbeitspaketen und

den Lieferobjekten besteht eine Hierarche, wie in Abb. 2.35 aufgezeigt.

Teilprojekte

Bei kleinen bis mittelgroßen Projekten liegt die Projektleitung in der Verantwortung einer

einzigen Person. Wenn bei sehr großen oder sehr komplexen Projekten die Führungs-

spanne für einen Projektleiter zu groß wird, ist es sinnvoll Teilprojekte zu führen und

die Projektleitungstätigkeiten (Planung, Kontrolle und Steuerung des Prozesses) auf zwei

oder mehr Personen aufzuteilen. Der Preis dafür sind zusätzliche Absprachen und Ko-

ordination zwischen den Teilprojektleitern und dem Gesamtprojektleiter. Teilprojekte zu

2.3

Phase Initialisierung

141

Projekt

Projektleiter

Teilprojekt 1

Arbeitspaket 2

Lieferobjekt

Tätigkeit

Arbeitspaket 1

Lieferobjekt

Tätigkeit

Teil-Projektleiter

Teilprojekt 2

Arbeitspaket 3

Lieferobjekt

Tätigkeit

Teil-Projektleiter

Abb. 2.35 Hierarchien im Projekt

bilden ist nur sinnvoll, wenn die Vorteile (Handhabbarkeit, Unabhängigkeit) überwiegen.

Lediglich eine inhaltliche Unterteilung in Arbeitspakete bzw. Tätigkeiten ist kein Grund

zur Einführung von Teilprojekten.

Gesamtprojektleiter und Teilprojektleiter müssen die Naht- oder Schnittstellen zwi-

schen den Teilprojekten absprechen und durchgängige Meilensteine wie in Abb. 2.40

dargestellt deﬁnieren, bei denen Entscheide für das gesamte Projekt gefällt werden. An-

lässlich eines Meilensteins müssen von allen Teilprojekten die entsprechenden Entschei-

dungsgrundlagen vorliegen, damit ein Go-/No-Go-Entscheid für das gesamte Projekt ge-

fällt werden kann.

Arbeitspakete

Das Gesamtprojekt wird in übersichtliche Arbeitspakete (Aufgabenpakete) aufgeteilt, mit

einfachen Schnittstellen und einer fachlichen Zuteilung der Aufgabenträger, so dass eine

klare Zuordnung der Verantwortlichkeiten möglich ist. Über die verschiedenen Phasen des

Projektes ist dafür zu sorgen, dass eine eindeutige Abgrenzung und eine zeitlich durch-

gehende Verantwortung der Aufgabenträger gegeben sind. Das Projekt soll vollständig

dargestellt werden.

142

Methodik

Als Arbeitspaket wird die Gesamtheit mehrerer Lieferobjekte und Tätigkeiten bezeich-

net, die in sich abgeschlossen sein müssen, um ein überprüfbares Resultat oder Ergebnis

zu erhalten. Für jedes Arbeitspaket wird ein Arbeitspaketverantwortlicher bestimmt. Ar-

beitspakete können auf zwei Arten zusammengestellt werden:

Top-down: das ganze Projekt wird schrittweise in kleinere Einheiten zerlegt mit sinn-

voller Abgrenzung der Arbeitspakete. Dies setzt Erfahrung mit ähnlichen Projekten und

einen guten Überblick über das Projekt voraus.

Bottom-up: Ist wenig Erfahrung vorhanden, wählt man dieses Vorgehen. Alle Tätig-

keiten, die einem in den Sinn kommen, werden im Team zusammengetragen. Anschlie-

ßend gruppiert man zusammengehörende Tätigkeiten zu Lieferobjekten und Arbeitspake-

ten. Am Schluss überprüft man, ob die aufgelisteten Tätigkeiten vollständig sind.

In großen oder komplexen Projekten wird für jedes Arbeitspaket eine Arbeitspaket-

beschreibung erstellt. Diese macht Angaben über Voraussetzungen (Input), Tätigkeiten,

die mit diesem Arbeitspaket ausgeführt werden, Resultate (Lieferobjekte, Output), den

für dieses Arbeitspaket benötigten Aufwand, die Verantwortlichen und die Rahmenbe-

dingungen. In „Voraussetzungen“ ist stichwortartig festgehalten, welche Angaben oder

Dokumente vorliegen müssen, damit die Arbeiten gestartet werden können. Abb. 2.36

zeigt ein Beispiel einer Arbeitspaketbeschreibung aus dem Praxisbeispiel der BLS.

Lieferobjekte

Die Lieferobjekte (Arbeitsergebnisse, englisch: Deliverables) sind die durch das Projekt

zu liefernden Ergebnisse wie beispielsweise ein Produkt, ein Service oder ein Konzept.

An den Lieferobjekten wird der Erfolg des Projektes gemessen.

Lieferobjekte sind Teil eines Arbeitspaketes.

Je nach Größe des Projekts werden Lieferobjekte und Arbeitspakete miteinander ver-

schmolzen und nicht unterschieden.

Projektziele – genau genommen Systemziele – und Lieferobjekte werden miteinander

verknüpft, um die Verbindungen und Zusammenhänge darzustellen.

Tätigkeiten

Die Tätigkeit (auch als Task bezeichnet) ist die unteilbare Einheit bei der Projektplanung.

Während für ein Arbeitspaket ein Team oder eine Abteilung verantwortlich sein kann, soll

eine Tätigkeit genau einer Person zugeteilt werden. Die Granularität der Tätigkeiten, d. h.

der intellektuelle und zeitliche Umfang, hängt insbesondere auch von der Erfahrung der

ausführenden Person ab.

2.3.11.4

Der Projektstrukturplan PSP

Der Projektstrukturplan PSP (englisch: Work Breakdown Structure WBS) ergibt sich aus

der geeigneten Gliederung aller Arbeitspakete.

Es gibt verschiedene Kriterien, nach denen der Projektstrukturplan gegliedert sein

kann. Er kann objektorientiert (inhalts-, ziel- oder produktorientiert), ablauforientiert

(Prozess-, Tätigkeits- oder funktionsorientiert) oder gemischtorientiert sein (objekt- und

2.3

Phase Initialisierung

143

T-TA

Arbeitspaketbeschreibung

Bezeichnung

Testkonzept Projekt Vertriebs-Back-End

Kontext / Ausgangslage

Im Projekt Vertriebs-Back-End werden Standardkomponenten (z.B. Fahrplan) vom

Markt eingekau und substanzielle Teile selber entwickelt. Das realisierte System

muss vor der Produkvsetzung systemasch überprü und getestet werden.

Ziel / Beschreibung

Erstellung eines Testkonzeptes für das Projekt Vertriebs-Back-End als Basis für den

Auau der notwendigen Testorganisaon und Tesnfrastruktur.

Auraggeber

Mike

Auragnehmer

Bruno, Thomas

Aufwand total [h]

80 h

Kosten extern

Keine externen Kosten

Starermin

1. Dezember 2015

Endtermin

31. Januar 2016

Abhängigkeiten

Keine

Input, Voraussetzungen

Die allgemeinen Vorgaben für BLS Projekte bezüglich Testen müssen berücksichgt

werden.

Resultat

Das Testkonzept beschreibt die Testziele, Testobjekte, Testarten, Tesnfrastruktur

sowie die Testorganisaon des Projektes. Es umfasst ebenfalls die Testplanung und

eine Deﬁnion des Testumfangs, als Tesallbeschreibungen oder als Verweis zu

den Tesällen in einem externen Tesool. Für jeden Tesall wird eine detaillierte

Tesallspeziﬁkaon erstellt. Die Testplanung legt den logischen und zeitlichen

Ablauf der Tests fest.

Das Testkonzept bildet die Grundlage, auf der die Testorganisaon und die

Tesnfrastruktur bereitgestellt und die Tests durchgeführt werden.

Abnahme der Resultate

Mike, Irina

Zielerreichungsgrad

Gut (mindestens 80%):

Testkonzept enthält alle Elemente gemäss der Beschreibung beim Resultat

Die BLS speziﬁschen Vorgaben werden eingehalten.

Das Testkonzept ist abgenommen und die Befunde sind eingearbeitet.

Sehr gut (100%):

Wie gut, zusätzlich wird das Testkonzept in der BLS Projekt Community als

Best Pracce angesehen.

Inhalt Genehmigung

Stelle

Datum

Unterschrift

Auftraggeber

Mike

Beurteilung nach Beendigung

Stelle

Datum

Unterschrift

Auftraggeber

Mike

Kommentar

Abb. 2.36 Praxisbeispiel BLS: Beispiel einer Arbeitspaketbeschreibung

144

Methodik

Staubsauger nach Baugruppen strukturiert

Kleines Flügelrad

Grosses Flügelrad

Filterhalterung

Filtereinsatz

Feinﬁlter

Klappventil

Kabelrolle

Dichtung

Geräuschisolation

Mechanisches

System

Motor

Netzschalter

Netzkabel

Überlastungsschutz

Steuerung

Bedienelemente

Elektrisches

System

Trägerplatte

Gehäuseboden

Filterdeckel

Bedienklappe

Luftschlauch

Düsen

Filterhalterung

Zwischenwand

Gehäuse

und Montage

Abb. 2.37 Beispiel einer objektorientierten PSP-Struktur

ablauforientiert). Manchmal wird auch noch zwischen ablauf- und funktionsorientiert

unterschieden. In produktionsorientierten Unternehmen wird die Projektstrukturierung

häuﬁg nach Objekten oder Inhalten, z. B. Baugruppen durchgeführt, was für die Bewirt-

schaftung und Bearbeitung eine günstige Aufteilung ergibt, wie in Abb. 2.37 aufgezeigt.

Abb. 2.38 zeigt ein Beispiel einer ablauforientierten PSP-Struktur.

Wichtiger ist jedoch, dass sich die Verantwortung eindeutig den Aufgabenträgern zu-

ordnen lässt. Häuﬁg entspricht die Strukturierung nach Funktionen den Fachbereichen

der Organisation wie Vertrieb, Marketing, Kundendienst, Entwicklung, Konstruktion oder

Produktion. In dienstleistungsorientierten Unternehmen ist diese Abgrenzung ebenfalls

sinnvoll.

Die Lieferobjekte (Deliverables) sind im Projektstrukturplan festzuhalten. Dies ist in

einem objektorientierten PSP gegeben. Anstelle vom Projektstrukturplan spricht man in

der Praxis teilweise auch vom Ergebnisplan.

2.3

Phase Initialisierung

145

Staubsauger nach Tätigkeiten strukturiert

Lösungsalternativen

Holzmodell

Strömungssimulation

Grobentwurf

Detailentwicklung

Energie-Optimierung

Prototyp-Prüfung

Qualiﬁkation

EMV-Test

Technik

Neue Produktionsvarianten

Zuliefervertrag

Ausbau Prüfung

Prototyp-Herstellung

Nullserie

Serienbereinigung

Serienproduktion

Produktion

Marktanalyse

Kundenbefragung

Pﬂichtenheft

Preisgestaltung

Distributionsnetz

Ausstellung

Werbekampagne

Einführungsprogramm

Marketing

Abb. 2.38 Beispiel einer ablauforientierten PSP-Struktur

Das Praxisbeispiel von Metrohm (Abb. 2.39) zeigt einen Projektstrukturplan mit den

Ebenen Projekt, Teilprojekt und Lieferobjekte.

Phasen- und Projektstrukturpläne können auch gemischt werden, wie dies Abb. 2.40

zeigt.

2.3.12

Projektauftrag

Der Projektauftrag ist die Entscheidungsgrundlage, ob das initiierte Projekt umgesetzt

werden soll oder nicht. Die Erstellung des Projektauftrags ist ein Vereinbarungsprozess

zwischen dem Projektleiter oder Product Owner, dem Auftraggeber und weiteren Stake-

holdern. Der Projektauftrag wird ähnlich erstellt wie die Angebotsanfrage, die mit dem

externen Kunden besprochen und ausgehandelt wird. Es ist die Aufgabe des angehenden

146

Methodik

Rack mit Becher

Hauptmodul

Greifer P&P Modul

Netzteil

alP

ciP

Messsystem

Dosiersystem

Prozesse

Proben

Equipment

Magnetrührer

Flaschenaufsatz

Liquid Adapter

Mainboard

Netzteil

Mainboard

Labor-Logik Service

OMNIS

Software

Bottle

Cap

Titrator

Sample Robot Pick & Place

Projektstrukturplan

Abb. 2.39 Praxisbeispiel Metrohm: Projektstrukturplan

Projektleiters oder Product Owners, den Projektauftrag zu formulieren. Der Projektleiter

als Verantwortlicher für den Prozess des Projektes weiß, welche Punkte zu regeln sind. Mit

der Unterschrift zeigt der Auftraggeber, dass der Projektleiter oder der Product Owner das

Anliegen richtig erfasst hat. Er gibt grünes Licht, meist für eine Projektphase.

Der Projektauftrag in der agilen Vorgehensweise ist knapper formuliert und weniger

detailreich als in der klassischen Vorgehensweise (beispielsweise bezüglich Umfang des

Projektes).

Unabhängig davon, ob ein Projekt von innen oder von außen kommt, gehören die Punk-

te gemäß Tab. 2.28 in einen Projektauftrag bzw. in ein Angebot.

Je nach Projekt und Unternehmen wird das Schwergewicht der Planung in der Initia-

lisierungsphase anders gelegt. In gewissen Fällen steht die Planung des ganzen Projektes

im Vordergrund. In anderen Fällen wird nur die nächste Phase im Detail geplant, die rest-

lichen Phasen nur grob.

2.3

Phase Initialisierung

147

Teilprojekt

Phase

Teilprojekt 1

Technik

TPL 1 :

Entwickler nn

Teilprojekt 2

Produktion

TPL 2 :

Produktionsassistent

Teilprojekt 3

Marketing

TPL 3 :

Marketingchef

MS 0

Entscheid Pﬂichtenheft und Produktentwicklung

Entwicklung

Entwicklungsversuche

Konstruktion Prototyp

Prototyp herstellen

Prototyp testen

Unterlagen bereinigen

Vorabklärung Produktion

Beratung Konstruktion

AVOR

Vorkalkulation

Werbekonzept

Servicekonzept

Verkaufskonzept

Vertragsverhandlungen

Wirtschaftlichkeit

MS 1

Entscheid Nullserie

Überführung in

die Produktion

Nullserieunterlagen

Nullserie testen

kleine Serienbereinigung

Produktionsmittel

beschaffen

Nullserie produzieren

Produktion optimieren

Service, Verkaufs-

organisation

Feldtest Nullserie

MS 2

Entscheid Serienproduktion und Markteinführung

Markteinführung

Dokumentation

bereinigen

Optimierung der

Serienproduktion

Werbekampagne

MS 3

Entscheid Folgeprojekte

Abb. 2.40 Beispiel einer Mischung aus Phasen- und Projektstrukturplan

Tab. 2.28 Inhalt Projektauftrag

Ausgangslage

– Umstände, welche zum Projekt geführt haben

– Vorgeschichte, projektauslösende Faktoren

– Beschreibung der Ist-Situation

– Probleme bzw. Potenziale der Ist-Situation

Ziele

Ziele im Sinne der Globalzielsetzung

Umfang des Pro-

jektes (Scope) und

Ergebnisse

Es ist wichtig, dass bei allen Projektbeteiligten Klarheit bezüglich des End-

ergebnisses und evtl. der wichtigen Zwischenergebnisse besteht.

– Wie soll das Endergebnis aussehen (Präsentation, Dokument, System)?

– Lieferumfang des Projektes: die wesentlichen Anforderungen in einer

summarischen Form (für Details kann auf Anforderungsdokumente ver-

wiesen werden). Daraus lassen sich die Lieferobjekte und Arbeitspakete

ableiten.

Abgrenzungen

An dieser Stelle wird klar abgegrenzt, was nicht durch das Projekt realisiert

wird. Die Projektgrenzen werden deﬁniert. Die Abgrenzungen können sich

auf Funktionen, Daten, Organisationseinheiten usw. beziehen.

Abhängigkeiten

und Einﬂüsse

Abhängigkeiten können beispielsweise bestehen zu:

– anderen Projekten (inhaltlich, zeitlich)

– externen Begebenheiten (z. B. Gesetzesänderungen)

Welchen wesentlichen Einﬂüssen ist das Projekt unterworfen?

148

Methodik

Tab. 2.28 (Fortsetzung)

Rahmen-

bedingungen

Rahmenbedingungen sind Vorgaben bzw. Restriktionen genereller Art für

das Projekt: zu berücksichtigende Vorgaben, bekannte Restriktionen.

Grundlagen

Auf welchen Vorarbeiten bzw. Grundlagen basiert das Projekt? Solche

Grundlagen können z. B. sein:

– Studien, Analysen

– Konzepte, Strategien

– Standards, Normen

– Ergebnisse aus früheren Projekten

Projektkosten,

Nutzen

– Wie groß wird der Aufwand für das Projekt sein?

– Sind die benötigten ﬁnanziellen und personellen Ressourcen budgetiert?

– Welcher Kostenstelle werden die geplanten Projektkosten belastet?

– Welche quantiﬁzierbaren/nicht quantiﬁzierbaren Nutzen bzw. Vorteile

ergeben sich aus der Umsetzung des Projektes?

Risiken

– Welche Risiken sind aus heutiger Sicht vorhanden oder erkennbar?

– Welche Maßnahmen können zu deren Reduktion getroffen werden?

– Welches sind die Konsequenzen bei Nichtrealisierung?

Vorgehen,

Terminplan

– Projektstruktur und Projektplan mit Meilensteinen

– Wann ist das Projekt beendet?

– Hinweise auf spezielle Vorgehensweisen

Projekt-

organisation

– Auftraggeber

– Auftragnehmer (Projektleiter)

– Projektteam(s), evtl. Stäbe

– Aufsichtsgremien (z. B. Projektausschuss)

– Eskalationsweg

Information,

Kommunikation

Hier ist der Informationsﬂuss bzw. die Kommunikation mit dem Auftragge-

ber, den Aufsichtsgremien, dem Benutzer und anderen interessierten Stellen

beschrieben. Die Berichterstattung kann schriftlich oder mündlich erfol-

gen. Dabei sollen Ersteller und Empfänger von Dokumenten wie auch die

Periodizität klar erkennbar sein:

– Fortschrittsbericht (Statusbericht)

– Projektplan

– To-Do- und Entscheidungs-Listen

– Projekt-Newsﬂash

Unterschriften

– Auftraggeber

– Projektleiter

– Controlling (bei Großprojekten)

– Entscheidungsinstanzen gemäß Finanzkompetenz

Anhang

– Projektplan

– Projektorganisation

– Detaillierung „Wirtschaftlichkeit“

– Ressourcenplan

– Geplante Aufwände

2.3

Phase Initialisierung

149

Tab. 2.29 Möglicher Inhalt bzw. mögliche Gliederung eines Projekthandbuches

Projektauftrag und

Leistungsplanung

– Projektauftrag, Projektvereinbarung

– Gliederung: Projektphasen, Projektstrukturplan

– Naht- bzw. Schnittstellen im Projekt

– Entscheidungsprozess

Projektumfeld

– Umfeldanalyse, Anspruchsgruppen

– Einbettung in die Unternehmensstrategie

Projektorganisation

– Organigramm

– Beschreibung der Rollen, Aufgaben und Kompetenzen

– Ansprechpartner und Adressen

– Spielregeln der Zusammenarbeit, Eskalationsvorgehen

Projektplanung

– Terminplanung

– Ressourcenplanung

– Kostenplanung

Controlling

– Qualitätssicherung, Prüfplan

– Risikomanagement

– Kontrolle und Steuerung

– Maßnahmen bei Abweichungen, Änderungswesen

Information,

Kommunikation

– Informations- und Kommunikations-Konzept

– Sitzungsplanung

– Sitzungs-, Workshop-Protokolle

– Fortschrittsberichte (evtl. unter Controlling)

– Ablagestrukturen, Dokumentenmanagement

2.3.13

Projekthandbuch/Projektmanagementplan

Das Projektmanagementhandbuch (Abschn. 2.7.4) regelt unternehmensweit, wie Projekt-

management in dem Unternehmen angewendet wird und gilt für alle Projekte. Das Pro-

jekthandbuch ist die speziﬁsche Anpassung für ein Projekt. Es muss auf die speziﬁsche

Situation des Projektes angepasst werden.

Das Projekthandbuch bzw. der Projektmanagementplan bildet die wichtigsten Prozess-

regelungen wie Vereinbarungen, Pläne, Strukturen, Organigramme und Spielregeln des

Projektes ab. Mögliche Inhalte des Projekthandbuchs sind in Tab. 2.29 dargestellt. Das

Projekthandbuch soll für alle Beteiligten Transparenz und Verbindlichkeit schaffen. Es

wird von Anfang an laufend geführt. Die aktualisierte Version wird der gesamten Projekt-

organisation zugänglich gemacht.

2.3.14

Kick-off-Veranstaltung

So wie ein Projekt beginnt, so wird es meist auch enden. Bezüglich der Führung eines

Projektes ist dem Anfang eines Projektes höchste Aufmerksamkeit zu widmen. Dabei

ist die Bildung und Etablierung der Projektorganisation ein wesentlicher Teil. Um in der

150

Methodik

Tab. 2.30 Checkliste: Ziele des Kick-off-Meetings

Inhaltsebene

– Die Produktvision, der zu realisierende Nutzen und die Hintergründe des Pro-

jektes sind dargelegt.

– Der gegenwärtige Projektstand bzw. Auftrag ist erörtert

– Die Absichten und Ziele sind erklärt

– Die Teammitglieder haben ein gemeinsames Aufgabenverständnis

– Die Zusammenhänge der einzelnen Aufgabengebiete sind erläutert

Beziehungs-

ebene

– Alle Teammitglieder lernen einander kennen

– Spielregeln werden vom Team deﬁniert und verabschiedet

– Identiﬁkation (Wir-Gefühl) mit dem Projekt und Projektteam entstehen (durch

Projektsinn, hervorheben der Besonderheiten dieses Teams)

– Es sind informelle Plattformen vorhanden, welche den zwischenmenschlichen

Meinungsaustausch ermöglichen

Organisations-

ebene

– Das methodische Vorgehen ist skizziert

– Die bereits bestehende Projektplanung oder Release-Planung ist vorgestellt

– Mögliche Problembereiche des Projektes sind angesprochen und zu deren Lö-

sung die verantwortlichen Teammitglieder bestimmt

– Die Projektorganisation ist aufgezeigt, die Ressourcen der einzelnen Mitglie-

der sind bekannt

– Die Kommunikations- einschließlich der Entscheidungswege sind festgelegt

– Die Aufgaben, Verantwortungen und Kompetenzen sind einzelnen Teammit-

gliedern oder Gruppen zugeteilt

– Der Sitzungsrhythmus und die Protokollführung sind festgelegt

Projektorganisation eine gute Basis zu legen, ist die Ausgestaltung und Durchführung

eines Kick-offs von zentraler Bedeutung. Je nach Art des Projektes und der zeitlichen

Einsetzung von Teammitgliedern ﬁnden zu verschiedenen Zeitpunkten mehrere Kick-offs

statt.

Das Kick-off-Meeting bildet den ofﬁziellen Start des Projektes. Dabei geht es nicht nur

um inhaltliche oder organisatorische Fragestellungen, sondern insbesondere auch um den

Auf- oder Ausbau der Beziehungen des sich gerade konstituierenden Projektteams (siehe

auch Abschn. 1.5). Die Checkliste gemäß Tab. 2.30 soll helfen, das Kick-off-Meeting

umfassend zu planen.

Es ist durchaus möglich, dass in einem Projekt mehrere Kick-off-Meetings durchge-

führt werden. Diese Kick-offs ﬁnden mit unterschiedlichen Teilnehmern statt oder an

unterschiedlichen Zeitpunkten auf der Zeitachse.

Ablauf einer Kick-off-Veranstaltung

Tab. 2.31 zeigt einen möglichen Ablauf eines sehr umfassenden Kick-off-Meetings. Ein

Kick-off-Meeting kann auch kürzer ausfallen. Die Buchautoren empfehlen, nicht nur eine

Informationsveranstaltung durchzuführen, denn es ist sinnvoll, dass gemeinsam mit der

Bearbeitung der Themen begonnen wird.

2.3

Phase Initialisierung

151

Tab. 2.31 Beispiel „Kick-off-Meeting“

Zeit

Thema

Ziel

Bemerkungen

08:00

Eintreffen der Personen, Kaffee

Ungezwungenes Wiedersehen

oder Kennenlernen

Kaffee, Früchte

usw.

08:30

Start, Begrüßung durch Pro-

jektleiter, Kick-off-Ablauf (mit

Zeiten) vorstellen, Projektleiter

stellt sich kurz vor und erzählt,

weshalb er Projektleiter ist

Pünktlicher Start, Orientie-

rung zur Sitzung, Transparenz,

Vertrauen schaffen

Flipchart

09:00

Projekt vorstellen, kurze Ge-

samthistorie und Globalziel

erklären

Infogleichstand schaffen, Pro-

jektziel einführen

Auftraggeber

09:15

Vorstellrunde der Projektmitar-

beiter, persönliche Verbindungen

zum Projekt besprechen: Was er-

warte ich persönlich von meiner

Mitarbeit im Projekt?

Sich kennenlernen, Bezug zum

Projekt herstellen, Wünsche,

Erwartungen, Befürchtungen

und entsprechende Projekt-

erfahrungen besprechen,

Vernetzung aufgleisen

Raster für Vor-

stellung vorgeben,

damit Sequenz

nicht zu lange geht

10:00

Pause

Informeller Austausch

10:15

Über den Projektstatus infor-

mieren oder diesen gemeinsam

erstellen

Information

Berichte, Flipchart,

Pinnwand, Video,

usw.

10:30

Stakeholder-Analyse erstellen,

Systemgrenzen aufzeigen

Umfeld und Abhängigkeiten

erkennen, Einstellungen der

Personen dazu identiﬁzieren

Pinnwand, Flip-

chart, Mindmap

10:45

Kräftefeld des Projektes

aufzeigen

Wissen, welche Kräfte das

Projekt fördern, welche es

hindern

11:00

Bereits erkannte Problemfelder

ableiten

Situationsanalyse, Daten zu

Risikoüberlegungen

Problemlisten

12:00

Mittagessen

13:00

Organisation des Projektes

aufzeigen bezüglich Zusam-

menarbeit und Projektablauf

(Lieferobjekte und Arbeits-

pakete)

Projekt organisatorisch auf-

gleisen, Engpässe erkennen,

Fixtermine regeln, Handlungs-

spielraum aufzeigen

Projektplan,

Organigramm

13:30

Zusammenarbeit regeln,

Sitzungsintervall, Dokumen-

tenmanagement und Protokoll

Kommunikation bestimmen,

Spielregeln

Flipchart

14:00

Nächste Schritte besprechen und

festlegen

Klaren Arbeitsplan schaffen

14:30

Jede Person nimmt kurz Stellung

zum weiteren Verlauf, ihrer Rol-

le und Funktion und der Planung

Engagement und Widerstand

erkennen, Verbindlichkeit

schaffen

15:00

Schlussworte vom Projektleiter

oder Projektauftraggeber

Wertschätzen und Wichtigkeit

zeigen

152

Methodik

Habe ich in der Planung

etwas vergessen

oder übersehen?

Kontrolle

Planen, wer die Arbeit

macht oder ob ich sie

delegieren kann.

Umsetzung

Problem-

lösungsprozess

Lösung mit dem grössten

Nutzen resp. dem besten

Zielerreichungsgrad

Lösung auswählen

Zielkriterien > SMART

Muss-/Wunschziele

Vorgehens-/Systemziele

Zielformulierung

Worum geht es genau?

Stärken/Schwächen,

Chancen/Risiken,

Ursachen/Wirkung

Situationsanalyse

Denken in Varianten

Lösungsalternativen suchen

Abb. 2.41 Der Problemlösungsprozess

2.3.15

Problemlösungsprozess

Ein wichtiges Vorgehens- und manchmal sogar Führungsinstrument ist ein systemati-

sches, strukturiertes Vorgehen beim Antreffen neuer Situationen. Der Problemlösungs-

prozess, wie in Abb. 2.41 aufgezeigt, ist ein strukturiertes Hilfsmittel für die Lösung von

fachlichen Problemen, gleichgültig, welcher Art sie sind. Er kann auf ein ganzes Projekt,

einen Teilaspekt daraus oder lediglich auf eine unerwartet aufgekommene Schwierigkeit

angewendet werden.

Häuﬁg wird auch der Begriff „Problemlösungszyklus“ verwendet um zu unterstreichen,

dass in der Realität das Finden einer Lösung kein linearer Vorgang ist und die einzelnen

Schritte nach Bedarf mehrmals durchlaufen werden können (iteratives Vorgehen).

Mit dem Problemlösungsprozess kommen die Vorteile einer systematisch strukturier-

ten Arbeitsweise gegenüber Free-Float- oder Hau-Ruck-Vorgehen zum Tragen. Zwar ist es

manchmal sinnvoll, eine „naheliegende“ Lösung direkt anzupacken, ohne den Ist-Zustand

bis ins Detail auszuleuchten oder sich gar Gedanken über Ziele und Lösungsmöglichkeiten

zu machen. Meistens übersieht man dabei jedoch wichtige Details und übernimmt Lösun-

gen, die in der Vergangenheit gepasst hatten, ohne Rücksicht auf die aktuell veränderte

Situation. Diese in der Praxis häuﬁg anzutreffende Situation wird als „Lösungsfalle“ oder

2.3

Phase Initialisierung

153

1. Situationsanalyse

2. Zielformulierung

5. Umsetzung

6. Kontrolle

Lösungsfalle

4. Auswahl

Erfahrung

Automatismen

Musterverhalten

3. Lösungen

Abb. 2.42 Die Lösungsfalle

„jumping to solution“ bezeichnet, wie in Abb. 2.42 aufgezeigt. Für Projekte, die Neuland

betreten, lohnt sich ein strukturiertes Vorgehen.

Der Problemlösungsprozess wird in jeder Projektphase durchlaufen. Der Akzent auf

die einzelnen Schritte des Problemlösungsprozesses verschiebt sich im Projektablauf:

während in der Anfangsphase der Schwerpunkt auf der Situationsanalyse und der Zielfor-

mulierung liegt, wird er in späteren Phasen auf der Lösungssuche bzw. Lösungsbewertung

und dem Entscheid liegen. Auch nimmt der Detaillierungsgrad von Phase zu Phase zu.

Alternativen zum Problemlösungsprozess

Der Nutzen des Problemlösungszyklus ist so groß. Der Problemlösungsprozess ist so uni-

versell einsetzbar, dass diese Systematik seit den 1960er Jahren immer wieder neu und

unter anderen Namen aufgetischt wurde.

Der Projektleiter wird mit unterschiedlichen Aufgaben und Problemstellungen kon-

frontiert. Je nach Situation ist das eine oder andere Modell (siehe Tab. 2.32) von der

Terminologie und dem methodischen Vorgehen her hilfreicher:

154

Methodik

Tab. 2.32 Alternativen zum Problemlösungszyklus

Design Thinking

– Hohe Benutzerakzeptanz

– Verstehen: Design Challenge

– Beobachten: User Centered Design

– Standpunkt deﬁnieren: Synthese über Persona

– Ideen ﬁnden: Kundenorientierte Lösungen, Denken in Varian-

ten

– Prototyp entwickeln: Iteratives Vorgehen

– Testen: frühe Feedbackschleifen

Lean/Six Sigma

(DMAIC, DMAEC)

– Verbesserung

– Optimierung eines

Geschäftsprozesses

– Deﬁne: welche Bedürfnisse der Kunden soll der Prozess er-

füllen?

– Measure: Ausprägung der Leistungsmerkmale des Prozesses

– Analyse: Ursachen der Abweichung von deﬁnierten Leis-

tungszielen identiﬁzieren

– Improve, Engineer: Lösungsmöglichkeiten für identiﬁzierte

Probleme suchen, Bewertungskriterien festlegen

– Control: Verbesserungen und neue Verfahren einführen und

überwachen

Deming-Kreis (PDCA-Zy-

klus), Shewhart-Zyklus,

kontinuierlicher Verbesse-

rungsprozess

– Plan: aktuellen Zustand analysieren, Verbesserungspotenziale

erkennen

– Do: ausprobieren, testen, praktisch optimieren im kleinen

Rahmen

– Check: Resultate überprüfen und freigeben

– Act: als Standard auf breiter Front einführen, Einhaltung mit

Audits regelmäßig überprüfen

Kepner-Tregoe

Problemlösungs- und Ent-

scheidungsmethodik

– Situationsanalyse (SA): Gesamtsituation erfassen

– Problemanalyse (PA): Problem genau beschreiben und ab-

grenzen

– Entscheidungsanalyse (EA): Ziele setzen, Lösungsalternati-

ven bewerten

– Analyse potentieller Probleme (APP): Schwierigkeiten er-

kennen und vorbeugende Maßnahmen ergreifen

Es kann etwas völlig Neues geschaffen werden, das vorher nicht existiert hat (neues

Produkt, neue Dienstleistung). Kreativität und Neuland betreten stehen im Vordergrund

(z. B. in Pionierprojekten).

Etwas, das vorher zufriedenstellend funktioniert hat, erfüllt plötzlich seine Funktion

nicht mehr. Fehlfunktion erkennen und Ursachensuche sind angesagt.

Bestehende Prozesse müssen verbessert oder optimiert werden.

In einem anderen Projektumfeld können die optimalen Vorgehensweisen abweichen,

oder es werden andere Begriffe verwendet. In der Forschung sind die Schritte z. B.: Li-

teraturstudium, Datenerhebung, Datenauswertung, Hypothese, Veriﬁzierung. Im sozialen

Bereich sind die Schritte: Beobachtung, Hypothese, Intervention.

2.3

Phase Initialisierung

155

2.3.16

Design Thinking

Mit zwei Entwicklungen hat sich der erfolgreiche Projektleiter zunehmend auseinander-

zusetzen:

Projektleiter kommen immer öfter in die Situation, dass sie auch für die Ausgestaltung

und Speziﬁkation der im Projekt zu entwickelnden Produkte verantwortlich sind.

Wird der Problemlösungsprozess rein sachlich umgesetzt, besteht das Risiko, dass das

Projekt trotz sachlich guter Leistung wegen mangelnder Akzeptanz wichtiger Stake-

holder nicht erfolgreich umgesetzt werden kann.

Design Thinking ist ein Ansatz zur Lösungsﬁndung mit hohem Nutzen aus Anwender-

sicht. Der Kunde oder der Benutzer – die beiden müssen nicht identisch sein, man denke

an einen Hersteller von Ticketautomaten mit Transportunternehmen als Kunde und Fahr-

gast als Benutzer – wird oft mit Produkten konfrontiert, die nicht seinen Bedürfnissen

entsprechen oder die nicht seine Rahmenbedingungen berücksichtigen.

Design Thinking verbindet ein strukturiertes, analytisches Vorgehen mit einer intuiti-

ven, kreativen Arbeitsweise:

Informationen strukturiert sammeln, ordnen und auswerten

Annahmen intuitiv formulieren, Ideen kreativ generieren und kundenorientierte Lösun-

gen entwickeln

Dabei setzt Design Thinking immer die wahren Bedürfnisse des Anwenders in den

Mittelpunkt und hilft, wahre Innovation zu schaffen. Das direkte Befragen der Anwender

führt selten zu radikal neuen Lösungen: Als Henry Ford die Menschen fragte, was sie

wollten, wurde ihm geantwortet: „Ein schnelleres Pferd“. Die innovative Antwort war ein

selbstbewegtes Fahrzeug, ein Automobil.

Design Thinking übernimmt bewährte Vorgehensweisen aus dem klassischen Pro-

blemlösungszyklus wie iterative Vorgehensweise und die Grundreihenfolge Problemana-

lyse ! Zieledeﬁnition ! Lösungssuche. Sie werden um weitere Aspekte ergänzt mit dem

Ziel, die Problemlösung konsequent am Kundennutzen – oder allgemeiner ausgedrückt:

an den Bedürfnissen der Stakeholder – auszurichten:

Arbeiten in ﬂexiblen Räumen: viel Platz an den Wänden, ﬂexible Möbel, das nötige

Werkzeug und Material für Visualisierung, aber auch Rückzugsorte, um neuen Ideen

auszuarbeiten.

Heterogene Teams, wobei Querdenker und Menschen mit einem sogenannten T-Proﬁl

einen besonders wertvollen Beitrag leisten können. Beim T-Proﬁl steht der vertikale

Balken für die Tiefe des fachspeziﬁschen und analytischen Wissens, das der Teilneh-

mer aus seiner Disziplin einbringt. Der horizontale Balken steht für die Eigenschaften

Neugier, Offenheit und Intuition, also die Fähigkeit, das eigene Wissen mit dem der

anderen vernetzen zu können und eine gemeinsame Sprache zu ﬁnden.

156

Methodik

Die Methode selbst besteht aus sechs Schritten, welche idealtypisch aufeinander fol-

gen, wie in Abb. 2.43 dargestellt. Es kann aber iterativ zwischen den einzelnen Schritten

gewechselt werden.

1. Das Problem verstehen

Der erste Schritt wird auch Design Challenge genannt und ist zusammen mit dem zweiten

Schritt eine Recherchephase. Hier werden die Symptome betrachtet. Daraus wird auf das

Problem, die Ursache geschlossen. Es werden Hypothesen aufgestellt. Gelingt es in dieser

Phase nicht, das wirkliche Problem zu erkennen, wird das Team eine Lösung entwickeln,

die vielleicht das Verschwinden des Symptoms bewirkt, aber wahrscheinlich nicht dessen

Ursache beseitigt.

2. Ergänzende Informationen durch Beobachtung

Basierend auf dem Human- bzw. User-Centered-Design-Ansatz wird der wesentliche Teil

der Recherche durch qualitative Untersuchungen bei Menschen durchgeführt. Das Be-

obachtete wird visualisiert, um es sich selber und dem Team bewusst zu machen. Nach

diesem Schritt sind die Teammitglieder zu Experten geworden.

3. Standpunkt deﬁnieren

Nun wird aus der Sicht der Stakeholder eine Synthese erstellt. Ein bewährtes Werkzeug

dazu ist die Persona, eine strukturierte Beschreibung eines idealtypischen Kundenseg-

ments für das Problem. Personas helfen, den Kundenfokus zu behalten.

4. Ideenﬁndung mit Kreativitätstechniken

Mittels Brainstorming oder anderer Kreativitätstechniken wird die Synthese mit konkre-

ten Lösungsansätzen weiterentwickelt und nimmt erste handfeste Formen an. Da das Team

inzwischen über ein gutes Problemverständnis aus der Sicht der Betroffenen verfügt, wer-

den mit hoher Wahrscheinlichkeit kundenorientierte Lösungen als solche identiﬁziert und

weiterentwickelt.

5. Prototyping

Schnelles, dafür iteratives Prototyping ist ein zentrales Element im Design Thinking. Ein

Prototyp kann verschiedenste Formen annehmen: Storytelling, Papiermodelle, Rollenspie-

le oder erste Softwareelemente (Clickable Prototypes) sind mögliche Formen. Anhand des

ersten Prototyps wird das Team von selbst auf Lücken oder Inkonsistenzen stoßen und die-

se bereits beheben können.

6. Test und Feedback

Der Prototyp wird mit deﬁnierten Stakeholdern getestet und geht in Feedbackschleifen zur

Verbesserung. Es ist für Benutzer oft viel einfacher, anhand eines konkreten Prototyps eine

Beurteilung vorzunehmen, als auf grüner Wiese das gewünschte Verhalten zu beschreiben.

2.3

Phase Initialisierung

157

Verstehen

Beobachten

Standpunkt

deﬁnieren

Ideen

ﬁnden

Prototyp

entwickeln

Testen

Problemanalyse

Lösungsﬁndung

Abb. 2.43 Die sechs Phasen im Design Thinking

Beim Testen ist es wichtig, auch kritische Stakeholder einzubeziehen, um die benötigte

Akzeptanz sicherzustellen.

Im Design Thinking gilt die Devise: Jeder Fehlschlag ist, wenn er früh erkannt wird,

ein Gewinn für das Fortschreiten des Innovationsprozesses.

2.3.17

Checkliste Abschluss Initialisierungsphase

Agile und klassische Vorgehensweise:

Ist das Globalziel des Projekts klar formuliert? Sind sich Auftraggeber und Pro-

jektleiter/Product Owner einig über die Ziele und Rahmenbedingungen?

Sind die Ziele so formuliert, als ob sie bereits erreicht wurden?

Sind die Ziele lösungsneutral und positiv formuliert, speziﬁsch, möglichst mess-

bar, widerspruchsfrei, anspruchsvoll, terminiert und zudem erreichbar? Wie

erkennen Sie, dass Ihre Ziele erreicht sind?

158

Methodik

Sind Zielkonﬂikte ausdiskutiert? Wurden die Stakeholder identiﬁziert und analy-

siert? Wer sind die relevanten Stakeholder?

Ist klar, welche Stakeholder welche Interessen und Einﬂussmöglichkeiten haben?

Gibt es Absichten, welche zum heutigen Zeitpunkt nicht offengelegt sind?

Unterstützen der Auftraggeber und das Management das Projektteam mit allen

ihnen zur Verfügung stehenden Mitteln?

Ist die Machbarkeit im Markt sowie im politischen und technischen Umfeld nach-

gewiesen?

Sind die relevanten Stakeholder identiﬁziert?

Ist die Projektwirtschaftlichkeit (Business Case) zum heutigen Zeitpunkt noch

erwiesen?

Wie sehen die Risiken aus? Sind die Risiken realistisch bewertet und allfällige

Unterschiede in der Bewertung bereinigt?

Wurden Maßnahmen zur Reduktion der Risiken formuliert?

Wurde ein Kick-off mit dem Projektteam durchgeführt?

Wurden im Projektauftrag folgende Themen geklärt:

– Zielsetzung

– Vorgehensplan: Methoden, Schritte, Meilensteine, Terminplan, Projektstruk-

turplan

– Einﬂussgrößen: Abhängigkeiten und Einﬂüsse

– Personalressourcen und Projektorganisation

– Projektkosten

– Rahmenbedingungen und Abgrenzungen

Wurden die absehbaren Folgekosten des Projektes abgeklärt und im Projektauf-

trag erwähnt?

Wird die Art der Zusammenarbeit regelmäßig gemeinsam reﬂektiert?

Speziﬁsche Punkte der klassischen Vorgehensweise:

Wurden die Anforderungen (Lastenheft) erarbeitet?

Wurden die Anforderungen auf ihre Güte überprüft?

Sind die Anforderungen priorisiert?

Wurden die künftigen Nutzer bei der Formulierung der Anforderungen einbezo-

gen?

Wie sieht die Projektorganisation aus?

Sind die Handlungskompetenzen und Verantwortlichkeiten vereinbart?

Sind klare und ausreichende Entscheidungskompetenzen und entsprechende

Führungsverantwortung der Projektleitung übertragen?

Sind adäquate interdisziplinäre Fachvertretung und Fachkompetenz im Projekt-

team sichergestellt?

2.4

Phase Konzept

159

Sind aktive Benutzer und Betroffene so einbezogen, dass möglichst hohe Akzep-

tanz erreicht werden kann?

Sind die Ressourcen verfügbar?

Ist ein Projektstrukturplan erstellt worden? Ist die Aufteilung in Teilprojekte

richtig vorgenommen bzw. vorgesehen? Sind kritische Entscheide terminlich

festgelegt?

Bis wann sind die Resultate oder Zwischenergebnisse zu erwarten? Wie sieht die

Planung für das Projekt aus?

Wie groß wird der geschätzte Aufwand in Personentagen, wie viel Geld soll über

die gesamte Projektdauer investiert werden?

Sind Aufwand, Termine, notwendiges Know-how und Verfügbarkeit von Schlüs-

selpersonen mit den neuen Erkenntnissen überprüft und realistisch?

Welche Engpassressourcen werden in welchem Zeitraum benötigt?

Sind allfällige Schätzungen (Mengen, Häuﬁgkeiten, Meilensteine, Kosten, Zei-

ten) realistisch? Ist die Schätzgenauigkeit angegeben?

Stehen die Fachspezialisten, erforderlichen Mittel und Ressourcen zum richtigen

Zeitpunkt zur Verfügung?

Speziﬁsche Punkte der agilen Vorgehensweise:

Wer ist Product Owner, Scrum Master und wie ist das Team zusammengesetzt?

Ist der Product Owner in der Stammorganisation gut verankert und hat möglichst

direkten Zugang zu relevanten Entscheidungsträgern?

Sind die Ressourcen verfügbar?

2.4

Phase Konzept

Bei der agilen Vorgehensweise steht in der Konzeptphase die Erarbeitung des Produkt-

konzeptes und des Anforderungskatalogs (Product Backlog) im Vordergrund. Die Pla-

nung erfolgt in einer weniger konkreten Form als bei der klassischen Vorgehensweise.

Als Planung wird ein Releaseplan erstellt. Die Konzeptphase sollte bei der agilen Vorge-

hensweise deutlich kürzer ausfallen als beim klassischen Vorgehen. Die Arbeit im agilen

Projekt beginnt mit dieser Phase.

In der klassischen Vorgehensweise werden in der Konzeptphase Lösungsvarianten

erarbeitet und beurteilt. Für die ausgewählte Variante werden ausführungsreife Pläne

erstellt und Lösungskonzepte und das Pﬂichtenheft erarbeitet. Die Bedürfnisse sämt-

licher Interessengruppen sind so weit möglich unter einen Hut zu bringen. Dabei ist es

wichtig, sich der eigenen Gewohnheiten bewusst zu sein. Die Phase „Konzept“ kann bei

großen Projekten in Hauptprojekt und Detailprojekt aufgeteilt werden. Durch die Auftei-

160

Methodik

lung entsteht ein weiterer Meilenstein. Dadurch wird vermieden, dass sich das Projektteam

in unwegsamem Gelände versteigt. Bei jedem Meilenstein entscheidet der Auftraggeber,

welche Variante weiterverfolgt werden soll. Er gibt auch die Mittel für die nächste Phase

frei.

2.4.1

Worauf kommt es in der Konzeptphase an?

Schritte dieser Phase

In der Konzeptphase sind die relevanten Anspruchsgruppen vertreten, sei dies im Projekt-

team bzw. in Teilprojektteams, in speziellen Arbeitsgruppen oder Begleitgruppen. Dabei

besteht oft die Tendenz, möglichst alle Vertreter einer Anspruchsgruppe zu beteiligen, was

die Projektorganisation schwerfällig und aufwändig macht.

Die Schritte dieser Phase sind aus Tab. 2.33 ersichtlich.

Tab. 2.33 Schritte der Phase Konzept

Agile Vorgehensweise

Klassische Vorgehensweise

Wichtigste

Schritte

– Die Idee mittels eines Produktkon-

zepts entwickeln und gegebenenfalls

mittels eines einfachen Modelles

visualisieren

– Mit dem Aufbau des Anforde-

rungskatalogs (Product Backlog)

beginnen

– Die Einträge im Product Backlog

priorisieren, schätzen und daraus

einen Releaseplan ableiten

– Information und Kommunikation

aufbauen und sicherstellen

– Dokumentationssystem etablieren

– Die Anforderungen bei Bedarf weiter

konkretisieren und überarbeiten

– Lösungsvarianten entwickeln (Höhe-

punkt der Kreativität in dieser Phase)

und auf die Zielkonformität prüfen

– Lösungsvarianten bewerten, eine Va-

riante vom Auftraggeber auswählen

lassen

– Das Lösungskonzept (Pﬂichtenheft) zu

der gewählten Variante ausarbeiten

– Mittel- und Ressourcenbedarf überprü-

fen und anpassen

– Detailplanung: Terminplanung und

Ressourceneinsatzplanung

– Information und Kommunikation auf-

bauen und sicherstellen

– Dokumentationssystem etablieren

Worauf ist

in der Kon-

zeptphase

besonders

zu achten?

Anhand der groben Projektplanung

mittels des Release-Plans wird die

Planung in der Realisierungsphase an-

lässlich der Sprint Planungen und der

Daily Standup Meetings konkretisiert

– Aufgrund der Anforderungen muss in

der Konzeptphase eine Lösungsvariante

gefunden und diese mittels eines Lö-

sungskonzeptes im Detail ausgearbeitet

werden

– Der in dieser Phase ausgearbeitete de-

taillierte Plan für das restliche Projekt

dient als Basis für die Fortschrittskon-

trolle im weiteren Verlauf des Projektes

2.4

Phase Konzept

161

Tab. 2.34 Ergebnisse der Konzeptphase

Agile Vorgehensweise

Klassische Vorgehensweise

Grundsatz

In der agilen Vorgehensweise

steht das „was“ im Vordergrund

In der klassischen Vorgehensweise

steht das „wie“ im Vordergrund

Zu beantwortende

Fragen

– Was soll umgesetzt werden, wie

sieht die Vision aus?

– Welcher Mehrwert soll realisiert

werden?

– Welche Lösungsvariante soll ausge-

wählt werden?

– Wie sieht die gewählte Lösung aus?

– Wie soll die gewählte Lösung umge-

setzt werden?

Prozessorientierte

Ergebnisse

– Aktualisierter Projektauftrag

(sofern notwendig)

– Releaseplan

– Projekt-Dokumentationssystem

– Phasenbericht

– Aktualisierter Projektauftrag (sofern

notwendig)

– Informations- und Kommunikations-

konzept

– Detailpläne für die Realisierung nach

klassischer Vorgehensweise

– Projekt-Dokumentationssystem

– Phasenbericht

Inhaltsorientierte

Ergebnisse

– Produktkonzept

– Erste Version des Product

Backlog (Anforderungskatalog)

– Lösungsvarianten sind entwickelt

– Eine Variante mit ausführungsreifen

Plänen ist ausgewählt

– Die bestimmte Lösung ist im Detail

mit den notwendigen Konzepten

(Pﬂichtenheft) ausgearbeitet (Die

Art und Weise der Lösungskonzepti-

on unterscheidet sich innerhalb von

Branchen und Projektarten sehr stark)

Ergebnisse der Konzeptphase

Die Kommunikation mit den Anspruchsgruppen braucht besondere Aufmerksamkeit, um

Vertrauen, Identiﬁkation und Unterstützung zu erreichen. Wichtige Instrumente dazu sind:

Informations- und Kommunikationskonzept und Projektmarketing. In der Konzeptphase

sind die Ergebnisse gemäß Tab. 2.34 von Bedeutung.

Phasenbericht

In manchen Organisationen ist es üblich, zum Abschluss einer Phase einen Phasenbericht

zu erstellen. Der Phasenbericht gibt eine kurze Übersicht über die erreichten Ergebnis-

se und Resultate. Dieses Dokument enthält die Auswertung bzw. Zusammenfassung der

Konzeptphase und bildet die Grundlage für die nächste Phase:

Ausgangslage: Voraussetzungen, Annahmen, aufgetretene Probleme, Konsequenzen

Erreichte Ergebnisse und Resultate

Sehr wertvoll ist ein kritischer Rückblick auf den Prozess während dieser Phase: was

lernt das Team daraus für die nächste Phase?

Ziele, neu identiﬁzierte Rahmenbedingungen

162

Methodik

Lösung, Lösungsvarianten

Auswirkungen auf Stakeholder, z. B. Kunden, Eigner, Personal

Nutzen und aktualisierte Wirtschaftlichkeitsrechnung, insbesondere Änderungen ge-

genüber der Initialisierung

Aktualisierte Projektorganisation

Gesamtplanung des Projektes, Planung der nächsten Phase, ﬁnanzielle Führung inkl.

Mittelbedarf für personelle Mittel und Sachmittel

Risiken

Antrag: Lösung und weiteres Vorgehen

Mit dem Meilenstein „Abschluss Konzeptphase“ wird die umzusetzende Lösungsvari-

ante formell deﬁniert und das weitere Vorgehen freigegeben.

Mensch und Team

Verschiedene Aspekte aus den Kompetenzbereichen Mensch und Team können in dieser

Projektphase relevant sein. Es ist aber auch möglich, dass sie in einer späteren Phase oder

gar nicht auftreten.

Mit dem unterzeichneten Projektauftrag startet die Phase Konzept. In der agilen Vor-

gehensweise beginnt in dieser Phase die effektive Projektarbeit mit der Erarbeitung der

Produktvision (Produktkonzept). In der klassischen Vorgehensweise müssen nun substan-

zielle und anspruchsvolle konzeptionelle Arbeiten geleistet werden. Das Team wird in

dieser Phase oft noch verändert: Neue Personen kommen dazu, weil mehr Kapazitäten be-

nötigt werden. Damit verändert sich das soziale Gefüge des Projektteams. Deshalb müssen

oft Maßnahmen der Initialisierung wiederholt werden.

Folgende Themen sind jetzt wichtig:

Arbeit am System (Abschn. 1.5.2): Mit dem ofﬁziellen Projektauftrag muss die Zusam-

menarbeit im Team formalisiert werden.

Vielseitigkeit und Kreativität (Abschn. 1.7): Wie in der Beauftragung sollte auch in der

Initialisierung dem Variantendenken und den kreativen Lösungsansätzen hohe Auf-

merksamkeit geschenkt werden.

Dynamik in Teams (Abschn. 4.2): Als Antwort auf ein mögliches „Storming“ gilt es,

durch ein „Norming“ die Rollen im Projekt weiter zu klären und möglicherweise an-

zupassen.

Selbstmanagement (Abschn. 3.8): Die Intensität der Arbeit fordert nun die einzelnen

Projektbeteiligten auch stärker in ihrem Selbstmanagement und in ihrem Verhalten in

Bezug auf Stress und Veränderung (Abschn. 3.5)

Motivation und Sinn (Abschn. 3.7): Wie gut gelingt es, dem Team Sinn und Nutzen des

Projektes zu vermitteln? Das hat einen starken Einﬂuss auf die intrinsische Motivation.

Anbindung des Projektes an die Linie (Abschn. 4.1.4): Die Art und Weise, wie ein

Projekt in die Linie integriert wird, beeinﬂusst die Entscheidungskompetenzen und den

Führungsstil der Projektverantwortlichen wesentlich.

2.4

Phase Konzept

163

Konkretisierung des Führungsansatzes (Abschn. 4.1.13.3) sowie der notwendigen

Macht und Autorität (Abschn. 4.1.3)

Projektkultur (Abschn. 4.1.14.2), multikulturelle Zusammenarbeit (Abschn. 4.1.14.4)

und möglicherweise auch Aspekte der virtuellen Zusammenarbeit (Abschn. 4.1.14.5).

2.4.2

Produktkonzept

Am Anfang steht die Idee. Mit der Erstellung des Produktkonzeptes – auch Produktvision

genannt – in der agilen Vorgehensweise wird diese Idee konkretisiert. Das Produktkon-

zept beschreibt den Nutzen für den zukünftigen Anwender des Produktes oder Services

und die wesentlichen Leistungsmerkmale.

Das Produktkonzept soll bewusst kurz und knapp formuliert werden. Dadurch wird der

Fokus auf das Wesentliche gelegt. Es empﬁehlt sich, das Produktkonzept mit Hilfe eines

physischen Modells zu visualisieren, wie in Abb. 2.44 am Praxisbeispiel der BLS gezeigt.

Mit dem Produktkonzept und dem Modell wird die Vision für das Projekt deﬁniert. Da-

mit lassen sich auf einfache Weise Stakeholder auf unterschiedlichen Managementstufen

efﬁzient abholen und für das Projekt gewinnen.

Das Produktkonzept beschreibt folgende Themen:

Bedürfnisse der Anwender/Kunden

Nutzen/Mehrwert für die Anwender/Kunden

Alleinstellungsmerkmale (Unique Selling Propositions)

Wesentliche Leistungsmerkmale und Funktionen

Zielgrößen

Das Produktkonzept wird vom Product Owner zusammen mit dem Team und Stakehol-

dern wie Anwender, Kunden, Marketing, Marktforschung, Produktmanagement, Vertrieb,

Herstellung erstellt.

Das Produktkonzept bildet die Grundlage für die efﬁziente Erstellung des Product

Backlogs.

2.4.3

Product Backlog

Ken Schwaber und Jeff Sutherland deﬁnieren das Product Backlog im Scrum Guide wie

folgt:

„Das Product Backlog ist eine geordnete Liste von allem, was in dem Produkt enthalten

sein soll. Es dient als einzige Anforderungsquelle für alle Änderungen am Produkt. Der

Product Owner ist für das Product Backlog, seine Inhalte, den Zugriff darauf und die

Reihenfolge der Einträge verantwortlich.

164

Methodik

Abb. 2.44 Praxisbeispiel BLS: Beispiel eines einfachen Modells zur Visualisierung der Produkt-

idee (Oberﬂäche für mobilen Ticketverkauf (App) auf dem Smartphone)

Ein Product Backlog ist niemals vollständig. Während seiner ersten Entwicklungs-

schritte zeigt es nur die anfangs bekannten und am besten verstandenen Anforderungen

auf. Das Product Backlog entwickelt sich mit dem Produkt und dessen Einsatz weiter. Es

ist dynamisch; es passt sich konstant an, um für das Produkt klar herauszustellen, was es

braucht, um seiner Aufgabe angemessen zu sein, im Wettbewerb zu bestehen und den er-

forderlichen Nutzen zu bieten. Sofern ein Produkt existiert, gibt es auch das dazugehörige

Product Backlog.

2.4

Phase Konzept

165

Im Product Backlog werden alle Features, Funktionalitäten, Verbesserungen und Feh-

lerbehebungen aufgelistet, die die Änderungen an dem Produkt in zukünftigen Releases

ausmachen. Ein Product-Backlog-Eintrag enthält als Attribute eine Beschreibung, die Rei-

henfolge, die Schätzung und den Wert. Product-Backlog-Einträge enthalten oft Testbe-

schreibungen, die ihre Vollständigkeit nachweisen, wenn sie fertig „Done“ sind.

Das Product Backlog entwickelt sich mit dem Einsatz eines Produktes, dessen Wertstei-

gerung sowie durch das Feedback des Marktes zu einer längeren, ausführlicheren Liste.

Anforderungen werden nie aufhören, sich zu ändern. Daher ist das Product Backlog ein

lebendes Artefakt. Änderungen an den Geschäftsanforderungen, Marktbedingungen oder

der Technologie können Änderungen am Product Backlog nach sich ziehen.

Häuﬁg arbeiten mehrere Scrum Teams gemeinsam an einem Produkt. Dann wird ein

einziges Product Backlog benutzt, um die anstehende Arbeit am Produkt zu beschreiben.

In diesem Fall kann ein Gruppierungsattribut für die Product Backlog-Einträge verwendet

werden.

Als Verfeinerung (Reﬁnement oder Grooming) des Product Backlogs wird der Vor-

gang angesehen, in dem Details zu Einträgen hinzugefügt, Schätzungen erstellt, oder die

Reihenfolge der Einträge im Product Backlog bestimmt werden. Die Verfeinerung ist ein

kontinuierlicher Prozess, in dem der Product Owner und das Entwicklungsteam gemein-

sam die Product Backlog-Einträge detaillieren. Bei der Verfeinerung des Product Backlogs

werden die Einträge begutachtet und revidiert. Das Scrum Team bestimmt, wann und wie

diese Verfeinerungsarbeit erfolgt. Sie sollte normalerweise nicht mehr als zehn Prozent

der Kapazität des Entwicklungsteams beanspruchen. Der Product Owner kann jedoch je-

derzeit die Einträge im Product Backlog aktualisieren oder aktualisieren lassen.

Höher angeordnete Product Backlog-Einträge sind generell klarer und weisen mehr

Details auf als niedrigere. Präzisere Schätzungen entstehen auf der Basis von größerer

Klarheit und Detailtiefe – je niedriger der Rang, desto weniger Details sind bekannt. Die

Product Backlog-Einträge, mit denen sich das Entwicklungsteam im kommenden Sprint

beschäftigen soll, werden so weit verfeinert, dass jeder von ihnen innerhalb des Sprints

fertiggestellt werden kann. Die Product Backlog-Einträge, für die das der Fall ist, werden

als bereit („Ready“) für die Auswahl durch das Entwicklungsteam in einem Sprint Plan-

ning angesehen. Ein Product Backlog Eintrag entwickelt diesen Transparenzgrad in der

Regel durch die oben beschriebenen Verfeinerungsaktivitäten.

Das Entwicklungsteam ist für alle Schätzungen verantwortlich. Der Product Owner

kann das Entwicklungsteam dahingehend beeinﬂussen, dass er ihm beim Verständnis der

Einträge hilft oder Kompromisse eingeht. Die endgültige Schätzung erfolgt immer von

denen, die auch die Arbeit erledigen werden.“ (Schwaber und Sutherland 2017, S. 15)

Die Aussagen können wie folgt zusammengefasst werden.

Das Product Backlog ist die Quelle der Anforderungen.

Das Product Backlog ist dynamisch und niemals vollständig oder widerspruchsfrei.

Verantwortlich für das Product Backlog ist der Product Owner

Die Einträge sind priorisiert.

166

Methodik

Abb. 2.45 Praxisbeispiel BLS: initialer Product Backlog BLS

Die Einträge weisen einen unterschiedlichen Detailierungsgrad auf.

Die Einträge sind bezüglich ihres Aufwands geschätzt.

Das Product Backlog ist eine Liste und kann als Tabelle in allen marktgängigen Tools

aufgebaut werden. In der Anfangsphase empﬁehlt sich auch eine Visualisierung mit Zettel

an einer Wand, wie Abb. 2.45 zeigt.

Ein Product Backlog lässt sich auch durch Schwerpunktthemen gliedern. Ein Schwert-

punktthema wird oft als Epic bezeichnet. Jedes Schwerpunktthema (Epic) wird in einem

Folgeschritt aufgeteilt in mehrere User Stories. Zu den User Stories können bei Bedarf

auch noch detaillierte Anforderungen (Requirements) erfasst werden.

Es empﬁehlt sich, zu den Epics und User Stories Akzeptanzkriterien (Deﬁnition of

Done) festzuhalten. Dadurch ist es für das Team rasch erkennbar, wann eine User Story

oder ein Epic für den Product Owner erfüllt ist. Die Akzeptanzkriterien helfen auch beim

Testen. Abb. 2.46 zeigt einen Ausschnitt aus dem Product Backlog mit Epics, Stories und

Requirements am Praxisbeispiel der BLS.

Ein Product Backlog muss am Anfang nicht mit möglichst vielen Anforderungen auf-

gefüllt werden. Dies wäre sogar eher kontraproduktiv. Es empﬁehlt sich, das Product

Backlog am Anfang eher klein zu halten. Darin sollten die wichtigen Anforderungen ent-

halten sein. Das Product Backlog sollte genügend Anforderung für mindestens zwei bis

drei Sprints enthalten.

Gute Anforderungen (User Stories) weisen die INVEST Merkmale gemäß Tab. 2.35

auf.

2.4

Phase Konzept

167

Key

Summary

Description

Status

Issue Type

VBE-463

E: Fahrplan 1

Ich als Endkunde möchte mit möglichst geringem Interaktionsaufwand meine bevorzugte Reiseroute zu einem von mir

definierten Zeitpunkt finden können.

Akzeptanzkriterien:

Vorschlagsliste für Stationen
Routenfindung ohne Standort
Soll-Fahrplandaten
Resultatsdarstellung in tabellarischer Form
Konsistenz der Kundeninformationen mit Bahnhofsanzeigen und existierenden Branchenvorgaben.
vgl. V580

Open

Epic

VBE-329

A: Routen-

findung ohne

Standort

Ich als Endkunde möchte von einer bestimmten Station zu einer anderen bestimmten Station finden und allenfalls Via-

Stationen definieren können.

Akzeptanzkriterien

* Bei der Eingabe von Stationsnamen (Aktualisierung bei jedem Tastendruck) werden mögliche Werte aus der Liste

aller UIC-Code-Stationen (Schweiz und grenznaher Bereich gemäss INFO+ Bahnhofsliste) vorgeschlagen.

* Die Sortierung der Stationsnamen erfolgt aufgrund einer statisch definierten Gewichtung (Basis Ein- und

Ausstiegszahlen).

* Der Autocompletion-Mechanismus bewirkt keine zusätzlichen Server-Roundtrips, sondern erfolgt ausschliesslich

lokal auf dem Gerät.

* Es muss sichergestellt werden, dass die Applikation über eine aktuelle Liste von Stationen verfügt.

* Der Autocompletion-Mechanismus erlaubt die Auffindung von Stationen auch bei leichten Tippfehlern (kein exact-

matching).

* Der gesuchte Teil kann sich irgendwo im Stationsnamen befinden (z.B. "mundigen" in "Ostermundigen").

* Via-Begrenzung auf 5 Stationen

* Via-Stationen sind per Default eingeklappt und müssen explizit vom Benutzer aktiviert werden.

* Wiederverwendung der Autocompletion-Logik zwischen mobilem und Online-Ticketshop.

Open

Story

VBE-36

R: Nationale

Fahrplan-

abfragen

Der Fahrplanserver muss nationale Abfragen in der Schweiz (alle Verkehrsmittel und Linien in der Schweiz) und im

grenznahen Gebiet der Schweiz (gemäss GA-Gültigkeitsbereich) unterstützen. Es werden alle Haltestellen und

Verbindungen angeboten, die INFO+ zur Verfügung stellt.

Closed

Requirement

VBE-38

R: Datums-

aktualisierung

bei der Fahrplan-

abfrage

Als Defaultwert für das Abfahrts- / Ankunftsdatum sowie die Abfahrts- / Ankunftszeit muss die Systemzeit verwendet

werden.

Closed

Requirement

VBE-199

Fehlertolerante

Suchfunktion

Die Suchfunktion des Fahrplanservers soll für falsche Texteingaben bei Abfahrts- und Ankunftsort eine Fehlertoleranz

aufweisen. Bei offensichtlichen Falscheingaben wie fehlende, falsche oder verdrehte Buchstaben soll der Benutzer

einen Vorschlag erhalten (Z.B. Züich statt Zürich oder Gern statt Bern).

Closed

Requirement

Abb. 2.46 Praxisbeispiel BLS: Ausschnitt Product Backlog mit Epcis, User Stories und Requirements

168

Methodik

Tab. 2.35 INVEST-Merkmale für gute Anforderungen

Independent

(unabhängig)

Anforderungen sollen möglichst unabhängig voneinander sein und

möglichst wenig gegenseitige Abhängigkeiten aufweisen.

Negotiable

(verhandelbar)

Zwischen Product Owner und Projektteam kann bezüglich der Reihen-

folge, Modiﬁkation oder Zerkleinerung von Anforderungen verhandelt

werden.

Valuable

(nützlich)

Anforderungen erbringen einen ausweisbaren Nutzen.

Estimatable

(schätzbar)

Die Umsetzung der Anforderungen kann durch das Team geschätzt

werden. Dies bedingt, dass die Anforderungen vom Team verstanden

werden.

Small (klein)

Die Beschreibung der Anforderung soll kurzgehalten sein.

Testable

(überprüfbar)

Alle Einträge im Product Backlog sind überprüfbar/können getestet

werden. Dies bedingt die Formulierung von Akzeptanzkriterien für

jeden Eintrag.

2.4.4

Releaseplan

In der agilen Vorgehensweise erfolgt die Planung auf drei Ebenen:

Release-Planung: Anzahl Sprints, Reihenfolge der Umsetzung der Anforderungen aus

dem Product Backlog, Produktivsetzungstermine von Releases

Sprint Planning: Planung eines Sprints, Sprint Backlog

Daily Scrum: Planung des Arbeitstages

Aufbauend auf dem Product Backlog wird der Releaseplan erstellt. Der Releaseplan

hat den Charakter einer Grobplanung und ist grobgranular, wie in Abb. 2.47 gezeigt. Im

Wesentlichen wird festgelegt, wie viele Sprints notwendig sind, um die Anforderungen

umzusetzen und in welcher Reihenfolge die Anforderungen aus dem Product Backlog

umgesetzt werden sollen. In einem agilen Vorgehen wie Scrum wird bewusst auf eine

Detailplanung zu Beginn des Projektes verzichtet. Die Detailplanung erfolgt jeweils zu

Beginn eines Sprints für die Dauer des zu planenden Sprints.

Sprint 4

Sprint 5

Sprint 6

Sprint 7

Back-End

Administraon VBE

SAV 1

Fahrplan 2

Fahrplan 3

App

Ticketverkauf 1

Payment 1

Ticketkontrolle 1

Service Après

Vente 1

Webshop

Fahrplan 1

Ticketverkauf 1

Payment 1

Ticketkontrolle 1

Epics

Abb. 2.47 Praxisbeispiel BLS: Releaseplan

2.4

Phase Konzept

169

Um einen Releaseplan zu erstellen, muss der Gesamtaufwand aus dem Product Back-

log (jeder Eintrag sollte geschätzt sein) und die Entwicklungsgeschwindigkeit des Teams

(Velocity) bekannt sein. Die Velocity ist von Team zu Team verschieden. Weiter sollte die

Velocity im Verlauf des Projektes in einem Team zunehmen. Die Velocity ist am Anfang

des Projektes tiefer, weil . . .

zuerst Wissen aufgebaut oder vertieft werden muss;

Teams zuerst zusammenwachsen und das optimale Zusammenspiel ﬁnden müssen;

idealerweise die Anforderungen mit einem hohen Risiko zuerst angegangen werden;

am Anfang benötigte Infrastruktur zuerst aufgebaut werden muss und

Hindernisse eher am Anfang auftreten.

Am einfachsten werden durch das Team zwei bis drei Sprints ausgeführt. Dabei wird

die Entwicklungsgeschwindigkeit gemessen. Jede User Story wurde zuvor mit Story

Points geschätzt. Am Ende des Sprints wird geschaut, wie viele Story Points umgesetzt

wurden. Die Summe der umgesetzten Story Points ergibt dann die Velocity, welche das

Team in einem Sprint umsetzt. Dabei ist es noch wichtig zu erwähnen, dass nur die durch

den Product Owner abgenommenen User Stories gezählt werden. Wurde eine User Story

nur teilweise umgesetzt oder enthält sie noch einen Fehler, so werden für diese User Sto-

rys keine Punkte gezählt. Es gilt das Motto „Alles oder nichts“. Erst nach dem Vorliegen

einer einigermaßen verlässlichen Velocity kann eine aussagkräftiger Releaseplan erstellt

werden. Das heißt, ein vernünftiger Releaseplan kann erst nach zwei bis drei Sprints

erstellt werden.

Um den Releaseplan zu erstellen, muss weiter deﬁniert werden, wie lange ein Sprint

dauert. Die Sprintlänge sollte konstant sein (Timeboxing, Abschn. 1.4.1.1) und zwischen

zwei Wochen bis zwei Monaten liegen. Sinnvolle Ausnahmen für eine Variation sind Ex-

plorationssprints (Sprints am Anfang zum Wissensaufbau), Release-Sprints (Sprint, um

ein Ergebnis oder Teilergebnis auszuliefern) oder Urlaubszeiten.

Der Releaseplan wird in folgenden Schritten erstellt:

Den benötigen Zeitraum ermitteln, basierend auf dem Gesamtaufwand des Product

Backlogs und der Velocity.

Die Reihenfolge festlegen, in welcher die Anforderungen umgesetzt werden, basierend

auf der Priorisierung im Product Backlog und einer möglichst gleichen Aufwandver-

teilung über die einzelnen Sprints.

Ein Ziel pro Sprint festlegen, wobei zu beachten ist, dass jeder Sprint ein auslieferbares

Produktinkrement liefert.

Festlegen, wann das Ergebnis oder ein Teilergebnis freigegeben wird.

Der Releaseplan dient der Optimierung von Kundenzufriedenheit und Wertschöpfung.

Die Verantwortung für die Erstellung des Release-Plans liegt beim Product Owner. Der

Product Owner wird dabei oft vom Team unterstützt.

170

Methodik

Tab. 2.36 Projektziele, Lastenheft und Pﬂichtenheft

Begriff

Erklärung

Fragestellung

Verantwortlich

Projektziele

Was ist der Scope/das

Ziel des Projekts?

Auftraggeber

Lastenheft

Anforderungskatalog Was kann das Produkt?

Requirements Engineering

Pﬂichtenheft

Summe der Lösungs-

konzepte

Wie wird das erreicht?

Auftragnehmer/Projektteam

2.4.5

Pflichtenheft – Lösungskonzept

Das Pﬂichtenheft ergibt sich aus der Summe aller Lösungskonzepte und beschreibt, wie

die geforderten Ziele und Anforderungen erreicht werden sollen.

Sofern die Ziele und Anforderungen lösungsneutral formuliert sind, lassen sie verschie-

dene Umsetzungsmöglichkeiten zu und erlauben dem Projektteam hohe Freiheitsgrade bei

der Auswahl der geeignetsten Lösungsvariante. Tab. 2.36 zeigt die unterschiedlichen Fra-

gestellungen bei Zielen, Lastenheft und Pﬂichtenheft.

Im klassischen Projektmanagement wird ein vollständiges Lastenheft vorausgesetzt,

um daraus das Pﬂichtenheft zu erarbeiten. Spätere Änderungen an den Anforderun-

gen, d. h. am Lastenheft, können zu völlig unterschiedlichen Lösungen mit erheblichen

Kosten- und Terminfolgen führen. Beispielsweise kann die nachträgliche Änderung der

Toleranz von 0 auf 0,08 mm bedeuten, dass eine gänzlich neue Produktionstechnologie

entwickelt und eingeführt werden muss, um diese Produktelinie herstellen zu können.

Diese zusätzliche Anforderung kann die Projektdauer und -kosten verdoppeln oder das

gesamte Projekt scheitern lassen.

In der Praxis synonym verwendete Begriffe für das Pﬂichtenheft sind u. a. Gesamtsys-

temspeziﬁkation, Sollkonzept, Fachspeziﬁkation und System Speciﬁcation.

2.4.6

Aufwandschätzung

Der Projektleiter ist in der klassischen Vorgehensweise für die Planung verantwortlich

(Planungsvorgehen, Methode, Hilfsmittel, Plausibilitätstest). Für die Aufwandschätzung

wird er aus den folgenden Gründen die Projektgruppe beiziehen:

Die ganze Projektgruppe zusammen hat mehr notwendiges interdisziplinäres Fachwis-

sen als der Projektleiter als Generalist. Dadurch entstehen die besseren Schätzungen.

Mit der gemeinsamen Planung sind die Teilprojektleiter besser informiert. Dadurch

steigt auch ihre Motivation und Bereitschaft, für ihre Tätigkeiten Verantwortung zu

übernehmen.

2.4

Phase Konzept

171

In der Praxis hat es sich bewährt, dass die Teilprojektleiter oder die Projektmitarbeiter

den Aufwand ihrer Arbeitspakete und Tätigkeiten abschätzen und anschließend mit dem

Projektleiter konsolidieren.

In der agilen Vorgehensweise ist das Team verantwortlich für die Durchführung der

Aufwandschätzung. Geschätzt werden die Product Backlog Einträge und während der

Sprintplanung die identiﬁzierten Tätigkeiten.

Idealerweise lässt sich die Projektgruppe bei der Schätzung von folgendem Credo lei-

ten:

Zählen vor Rechnen vor Expertenmeinungen

Der Grund für diese Empfehlung liegt in der abnehmenden Genauigkeit der Schätzme-

thodik.

2.4.6.1

Bedeutung der Aufwandschätzung in der klassischen

Vorgehensweise

Die Aufwandschätzung ist in der klassischen Vorgehensweise die Basis für die Berech-

nung der Projektdauer (Terminierung) und der Projektkosten. Das Unternehmen stellt

sich die Fragen, ob das Projekt realisiert werden soll, ob die Mittel im vorgesehenen

Zeitrahmen verfügbar sind, ob das Projekt wirtschaftlich ist, oder welche Investition von

mehreren Möglichkeiten die bessere Alternative zur Zukunftssicherung ist. Die Güte der

Entscheidungen ist also von der Genauigkeit der Aufwandschätzung abhängig. Für Un-

ternehmen, die ihren Kunden verbindliche Preisangebote machen müssen, z. B. im Engi-

neering oder im Architekturbereich, ist eine sehr genaue Aufwandschätzung notwendig

und überlebenswichtig, um Verluste zu vermeiden.

Unter diesem Aspekt hat die Aufwandschätzung und die damit verbundene Unsicher-

heit eine große Bedeutung. Eine brauchbare Aufwandschätzung durchzuführen setzt Er-

fahrung, Sorgfalt und Vorbereitung voraus.

Grundsätzliche Möglichkeiten für die Aufwandschätzung:

Erfahrung und Analogie durch Vergleich von Lieferobjekten oder Arbeitspaketen mit

schon realisierten ähnlichen Aufgabenstellungen (Erfahrungswerte von ähnlichen Pro-

jekten)

Analytisch: Die Aufgabe wird in einzelne, übersichtliche Tätigkeiten oder Funktionen

zerlegt, deren Aufwand wird geschätzt

Durch Kombination dieser Möglichkeiten

Viele Schätzverfahren beruhen auf Erfahrungswerten. Diese müssen durch Auswertung

vieler Projekte bei Projektabschluss über einen längeren Zeitraum systematisch aufgebaut

werden. Die Lieferobjekte oder Arbeitspakete müssen dabei klar strukturiert und abge-

grenzt sein. Aus der Analyse der Ist-Werte abgeschlossener Projekte werden bereinigte

Aufwandswerte sowie Einﬂussfaktoren für die Zukunft erarbeitet. Mögliche Einﬂussfak-

toren sind: Umfang und Komplexität der Aufgabe, Erfahrung der Ausführenden, Akzep-

tanz bei Betroffenen, verfügbare Infrastruktur, geltende Vorschriften usw. Es sind nur die

172

Methodik

wichtigsten Einﬂussfaktoren auszuwählen. Diese Kennwerte sind nur gültig für das Un-

ternehmen und die Projektart, für die sie ausgewertet wurden.

Ein Unternehmen muss ein Schätzverfahren auswählen und seinen Verhältnissen an-

passen. Damit sie über eine ganze Organisationseinheit im Unternehmen anwendbar sind,

müssen die Deﬁnitionen und Abgrenzungen der Lieferobjekte und Arbeitspakete und de-

ren Inhalte einheitlich deﬁniert, interpretiert und gehandhabt werden. Erfahrungswerte

können nicht unbesehen von anderen übernommen werden.

Bei vielen Verfahren wird empirisch eine Korrelation gesucht zwischen einer oder

mehreren Variablen im Projekt (z. B. Resultatgrößen, Anforderungen des Kunden) und

dem dafür notwendigen Zeitaufwand in Personenmonaten. Der Zusammenhang kann als

Formel oder Graﬁk dargestellt werden. Beispiele für Variablen: Leistungsfähigkeit oder

Genauigkeit einer Anlage, Volumen eines Baues, Anzahl Verarbeitungen oder Function

Points bei einer Software. Werden die Anforderungen des Kunden als unabhängige Var-

iable verwendet, so können diese Methoden schon in frühen Projektphasen eingesetzt

werden (z. B. zur Angebotserstellung), bevor der genaue Lösungsweg im Detail bekannt

ist.

2.4.6.2

Planning Poker/Story Points

Die Schätzmethode mit Story Points ist eine häuﬁg verwendete Methode in der agilen Vor-

gehensweise. Das Projektteam schätzt für jede User Story (oder Anforderung/Baustein)

eine Größe. Dabei werden Karten mit den an den Fibonacci-Zahlen angelehnten Wer-

ten 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40 oder mit 100 verwendet. Nachdem die User Story

vorgestellt wurde, schätzt jedes Mitglied des Projektteams den Aufwand und legt die Kar-

te verdeckt auf den Tisch. Sobald alle Mitglieder geschätzt haben, werden die Karten

aufgedeckt und verglichen. Stimmen die Schätzungen nicht überein, so begründen die

Mitglieder mit der höchsten und tiefsten Schätzung kurz ihre Einschätzung. Danach gibt

es weitere Schätz- und Diskussionsrunden bis ein Konsens erzielt wurde.

Die Anzahl Story Points für die Umsetzung einer User Story sagt direkt noch nichts

über den effektiven Aufwand aus. Sobald das Projektteam arbeitet, kann ein Erfahrungs-

wert gebildet werden, wie viele Story Points durch das Team in einem Sprint realisiert

werden können. Die Umsetzungsgeschwindigkeit (Velocity) im Team nimmt mit jedem

Sprint zu.

2.4.6.3

T-Shirt Sizing

Oft ist in einer frühen Phase des Projektes schwierig, die exakten Aufwände zu schätzen.

Mitarbeiter aus Marketing oder Verkauf müssen jedoch oft in einer frühen Phase des Pro-

jektes Entscheide zum Projektumfang fällen. Ein Ingenieur ist jedoch nicht in der Lage,

eine exakte Schätzung ohne deﬁnierte Speziﬁkationen zu machen. Um dieses Dilemma

aufzulösen, empﬁehlt es sich, bewusst zu machen, dass in einer frühen Phase keine milli-

metergenauen Schätzungen notwendig sind.

Bei der T-Shirt Sizing Methode klassiﬁzieren die Entwickler die Größe jeder Anforde-

rung in Relation zu anderen Anforderungen in die T-Shirt Größen Small, Medium, Large

2.4

Phase Konzept

173

oder Extra Large. Parallel dazu klassiﬁzieren die Vertreter aus Marketing und Verkauf den

Businesswert der Anforderungen mit der gleichen Skala.

Durch die Gegenüberstellung von Businesswert und Aufwand können mit dieser ein-

fachen Methode qualiﬁzierte Diskussionen über den Projektumfang geführt werden. Ein

Beispiel: Ich möchte Anforderung A umgesetzt haben, da diese einen Businesswert von

Extra Large darstellt und mit einem Aufwand von Medium umgesetzt werden kann. Dafür

verzichte ich auf die Anforderung B, da der Aufwand Large ist, und der Businesswert nur

mit Small eingeschätzt wurde.

2.4.6.4

Multiplikatoren Methode

Die zu realisierende Aufgabe wird in kleine, überblickbare Einheiten zerlegt, von denen

man den Aufwand kennt. Oder sie wird an einem Beispiel ausprobiert: Anzahl Modu-

le, Anzahl Seiten, Anzahl Graﬁken. Der Aufwand pro Einheit mal die Anzahl Einheiten

ergibt summiert über alle Einheitenarten den Gesamtaufwand.

2.4.6.5

Prozentsatzmethode

Die Prozentsatzmethode gibt für jede Phase Erfahrungswerte für die Prozentanteile des

Gesamtaufwandes an. Die Prozentanteile pro Phase sind stark von der Projektart und

von dem Unternehmen abhängig. Eine Phase wird detailliert geschätzt und realisiert.

Wenn diese Phase abgeschlossen ist, wird daraus auf das ganze Projekt geschlossen. Vor-

sicht ist angebracht, wenn aus einer ersten kleinen Projektphase mit wenig Aufwand auf

das ganze Projekt geschlossen werden soll. Das Verfahren eignet sich aber gut als Plau-

sibilitätstest zur Überprüfung von Schätzwerten, die auf andere Art erarbeitet wurden.

Die Erfahrungswerte oder Kennzahlen müssen von Projekten stammen, die unter ver-

gleichbaren Rahmenbedingungen erarbeitet wurden (z. B. gleiche Infrastruktur, gleiche

Unternehmenskultur).

2.4.6.6

Expertenschätzung (Delphi Methode)

Bei großer Unsicherheit bezüglich der Aufwandschätzung sind Expertenbefragungen ver-

breitet. Die Delphi-Methode befragt mehrere Experten unabhängig voneinander. Die un-

terschiedlichen Schätzwerte werden allen anonym vorgelegt. In weiteren Runden nutzen

die Experten die Möglichkeit, ihre Argumente bekannt zu geben und ihre Werte noch

anzupassen, bevor die Gruppenmeinung formuliert wird.

Eine andere zweckmäßige Vorgehensweise ist die Schätzklausur. Hier kommen alle

ausführenden Fachspezialisten vorbereitet zusammen und geben ihre Werte und Argu-

mente bekannt. Dadurch ﬁndet ein willkommener gruppendynamischer Prozess statt, der

vom Projektleiter moderiert wird. Ziel einer Schätzklausur ist es, am Schluss eine konso-

lidierte Schätzung zu haben, bei welcher die Fachspezialisten einen Konsens erreichen.

2.4.6.7

PERT (Program Evaluation and Review Technique)

Bei Projekten mit großer Unsicherheit (z. B. Pionierprojekte, Akzeptanzprojekte, For-

schungsprojekte) kann die Streuung mitberücksichtigt werden. Dabei wird pro Arbeits-

174

Methodik

paket ein wahrscheinlicher Zeitaufwand WZ (häuﬁgster Fall) geschätzt und zusätzlich

ein minimaler Zeitaufwand MinZ (optimistischer, günstigster Fall) sowie ein maximaler

Zeitaufwand MaxZ (pessimistische Schätzung, ungünstigster Fall). Die Planung wird mit

einem einzigen Planwert weitergeführt:

Planwert D .MinZ C 4 WZ C MaxZ/ =6

2.4.6.8

Reserven

Schon bei mittelgroßen Projekten bezüglich der Anzahl Lieferobjekte und Arbeitspake-

te wirkt sich der statistische Ausgleich günstig auf die Abweichung im Gesamtaufwand

aus, sofern kein systematischer Fehler in den Einzelschätzungen vorliegt. Auch bei sorg-

fältiger Planung passiert Unvorhergesehenes, werden Aufwandposten vergessen, kommen

kleine Änderungen dazu oder wird der zu leistende Aufwand unterschätzt. Darum braucht

ein Projekt Projektreserven. Diese können als Geldreserve ausgewiesen werden. Der Pro-

jektleiter verfügt über diese Projektreserve. Wenn ein Projektmitarbeiter bei seinen Lie-

ferobjekten oder Arbeitspaketen eine Überschreitung hat, die er nicht mehr innerhalb

seines eigenen Lieferobjektes oder Arbeitspaketes auffangen kann, dann informiert er

den Projektleiter. Dieser kontrolliert so den Verbrauch der Projektreserve und kann sei-

ne Kulanz gegenüber wünschbaren Änderungen der Situation anpassen. Wenn in einem

Unternehmen keine Projektreserven gebildet werden dürfen, so sollte sich der Projektlei-

ter überlegen, versteckte oder stille Reserven zu bilden.

2.4.6.9

Typische Fehler in der Aufwandschätzung

Aufwände zu schätzen ist immer mit Ungewissheiten verbunden. Es gibt immer wieder

klassische Fehler in der Schätzung von Aufwänden:

Sich ändernder Funktionsumfang

Vergessene Aktivitäten

Unbegründeter Optimismus

Chaotischer Entwicklungsprozess

Subjektivität

Schätzungen aus dem Handgelenk

Ungerechtfertigte Präzision

Geschäftsbereiche oder Technologien, die wenig vertraut sind

Falsche Konvertierung der geschätzten Zeit in Projektzeit (z. B. Projektteam arbeitet

acht Stunden am Tag und fünf Tage pro Woche)

2.4.7

Ablauf/Terminplan

2.4.7.1

Ablauf- und Terminplan erstellen

Der Inhalt der Lieferobjekte und Arbeitspakete wird jetzt weiter detailliert und in einer Tä-

tigkeitsliste vollständig erfasst. Alle durchzuführenden Tätigkeiten, das heißt alles, was

2.4

Phase Konzept

175

Tätigkeiten und Termine

Datum:

Nr. Tätigkeiten

Massnahmen

Vorgang

Verant-

wortlich

Vorbe-

din-

gung

Dauer

Wochen

Terminplanung resp. Balkenplan

1 Projekt

2 Phase 1

3 Tätigkeit A

4 Tätigkeit B

5 Tätigkeit D

6 Tätigkeit E

7 Tätigkeit C

3;6

8 Tätigkeit F

9 Tätigkeit G

10 Vorbereitung MS

4;9

11 MS-Entscheid

12 Phase 2

13 Arbeitspaket H

Abb. 2.48 Beispielhafte Tätigkeitsliste mit Balkenplan (Gantt-Diagramm)

Zeit oder Geld braucht, inklusive Meilensteinüberprüfung, wird vollständig und soweit

möglich chronologisch aufgelistet. Jede Tätigkeit erhält eine eindeutige Identiﬁkations-

nummer wie in Abb. 2.48 gezeigt.

Damit wird für jede Tätigkeit – soweit bekannt – die ausführende Stelle oder der ver-

antwortliche Fachbereich eingetragen. Die ausführende Stelle muss die für die Tätigkeit

notwendige Fachkompetenz aufweisen und zum vorgesehenen Zeitpunkt über genügend

freie Kapazität verfügen. Bei Engpassressourcen soll die Verfügbarkeit mitberücksichtigt

werden, sobald diese grob bekannt ist.

Der Fachspezialist schätzt den für die Problemlösung notwendigen Zeitaufwand und

die benötigte Durchlaufzeit. Zeitaufwand ist der Zeitbedarf des Aufgabenträgers in Perso-

nenmonaten, -wochen, -tagen oder -stunden, der notwendig ist, um alle mit dem Arbeits-

paket zusammenhängenden Aufgaben unter Berücksichtigung der voraussichtlich zum

Einsatz kommenden Ressourcen vollständig zu lösen.

Die Durchlaufzeit (Dauer) ist die kürzeste Zeitdauer, die notwendig ist, um den zu-

vor deﬁnierten Aufwand unter Berücksichtigung der Verfügbarkeit von Engpassressour-

cen, von unumgänglichen Wartezeiten und anderen Rahmenbedingungen zu leisten. Bei-

spiel: Ein Maler braucht fürs Vorbereiten und Spritzen einer Wanne vier Stunden. Dann

braucht die Wanne 72 h Trocknungszeit, bis der nächste Arbeitsgang möglich ist. Der Ma-

176

Methodik

ler braucht noch einmal vier Stunden für das Schleifen der Wanne. Der Zeitaufwand für

den Maler ist also acht Stunden, die Durchlaufzeit aber vier Tage.

Anschließend wird die Reihenfolge der Tätigkeiten festgelegt, die arbeitstechnisch

am sinnvollsten oder sogar notwendig ist. Bei jeder Tätigkeit sind die Fragen zu beant-

worten: Welche Resultate müssen vorliegen? Welche Rahmenbedingungen müssen erfüllt

sein, damit die Tätigkeit gestartet werden kann? Diese zeitlichen Abhängigkeiten werden

in der Tätigkeitsliste als Vorbedingungen eingetragen. Mit diesen Angaben kann anschlie-

ßend eine Terminierung erfolgen.

2.4.7.2

Terminierung, kritischer Pfad und Schlupf

Die Terminierung kann mit Hilfe der Balkenplantechnik (Gantt-Diagramm) ausgeführt

werden. Die Terminierung liefert den Endtermin und die Zwischentermine des Projek-

tes, unter Berücksichtigung der Abhängigkeiten. Der Planungsvorgang ergibt für jede

Tätigkeit einen frühesten und einen spätesten Anfangs- und Endtermin. Der früheste End-

termin gibt an, wann eine Tätigkeit frühestens fertig sein kann, wenn alle Bedingungen

bestmöglich erfüllt sind. Der späteste Endtermin gibt an, wann die Tätigkeit spätestens

abgeschlossen sein muss, damit keine Verzögerung des Projektes entsteht.

Sind spätester und frühester Termin zweier aufeinanderfolgender Tätigkeiten unter-

schiedlich, hat die vorausgehende Tätigkeit zeitlichen Spielraum (Schlupf, Slack, Puffer).

Der Schlupf ist diejenige Zeit, um die eine Tätigkeit verzögert sein darf, ohne dass dies

eine Auswirkung auf den Endtermin hat. Der kritische Pfad ist die Verbindung aller Tä-

tigkeiten, die keinen Schlupf haben. Er bestimmt gleichzeitig den Endtermin. Wenn auf

diesem Pfad eine Tätigkeit verzögert wird, verschiebt sich der Endtermin des Projektes

um das Ausmaß dieser Verzögerung. Damit der Projektleiter bei Bedarf frühzeitig Maß-

nahmen ergreifen kann, muss er die Tätigkeiten auf dem kritischen Pfad regelmäßig und in

sinnvollen Abständen überprüfen wie ein Steuermann, dessen Schiff nur mit Verzögerung

auf Korrekturen reagiert.

Der Balkenplan (Gantt-Diagramm) zeigt in einer kompakten und anschaulichen Dar-

stellung den frühestmöglichen Anfang, den frühestmöglichen und den am spätesten mögli-

chen Endtermin pro Tätigkeit. Dauer, Schlupf, zeitliche Relation der einzelnen Tätigkeiten

und die Abhängigkeiten untereinander sind anschaulich sichtbar, wie Abb. 2.49 zeigt.

Abb. 2.50 zeigt anhand des Praxisbeispiels von Metrohm einen Auszug aus dem

Ablauf- und Terminplan in zwei Detailierungsstufen. Das Bild zeigt auch den laufenden

Austausch zwischen dem Projekt und der Systemarchitektur.

2.4.7.3

Genauigkeit in der Ablauf- und Terminplanung

Wie genau soll man Termine, Ressourcen und Kosten planen? Hat die Projektleitung das

Projekt besser im Griff, je genauer sie plant?

Jede Planung ist eine Hypothese zur Zukunft. In manchen Projekten – besonders bei

denjenigen, die einer hohen Dynamik ausgesetzt sind – wird die zukünftige Realität oft

eine andere sein als die Vorstellung darüber. Es lohnt sich deshalb, die Projektdyna-

mik einzuschätzen: kann mit einem relativ ruhigen Projektverlauf gerechnet werden, be-

2.4

Phase Konzept

177

Tätigkeiten

Zeit

Kritischer Pfad

Schlupf

Abb. 2.49 Balkenplan mit kritischem Pfad und Schlupf

steht eine große Gewissheit über die einzelnen Ereignisse und Aktivitäten, oder muss mit

Unsicherheiten, vielen Änderungen und Überraschungen gerechnet werden? Beispiele:

Bei einem „normalen“ Einfamilienhaus auf problemlosem Grundstück sind die einzel-

nen Planungs- und Realisierungsschritte erprobt und bis zur Inbetriebnahme relativ sicher

planbar. Es handelt sich um ein sog. Standardprojekt (siehe Abschn. 1.2.1). Eine detail-

lierte Planung ist hier sehr hilfreich, um Termine und Kosten einhalten zu können. Bei der

Entwicklung eines neuen Produktes oder einer Software, bei der nach jedem Schritt neue

Erkenntnisse die Situation verändern oder aus der Umwelt neue Impulse einﬂießen, wäre

eine genaue Planung ein Hindernis. Sie wirkt wie eine Schiene mit ﬁxierten Erwartun-

gen, die man möglichst erfüllen will. Iterations- bzw. Lernschleifen werden so erschwert,

neue Ideen werden ausgeblendet. In diesem Fall ist es zweckmäßiger, Meilensteine oder

Terminﬁxpunkte einzuplanen, um dazwischen ﬂexible Planungs- und Controlling-Instru-

mente wie Kanban anwenden zu können. Besser wäre es noch, ein solches Projekt mit der

agilen Vorgehensweise abzuwickeln.

Abb. 2.51 zeigt, dass die Schätzgenauigkeit im Verlauf des Projektes besser wird.

178

Methodik

Terminplan

Abb. 2.50 Praxisbeispiel Metrohm: Ablauf- und Terminplan

2.4.7.4

Vorgehensweisen bei der Planung

Bei der Planung geht man häuﬁg von Vorgaben aus (z. B. Abschlusstermin) und unterteilt

die Arbeitsschritte immer feiner bis auf einzelne Tätigkeiten, deren Aufwand beurteilt

werden kann. Auf dieser Ebene wird eine detaillierte Termin-, Ressourcen- und Kosten-

planung durchgeführt. Die Resultate werden in verdichteter Form dargestellt und mit den

Vorgaben verglichen, siehe Abb. 2.52. Wenn Abweichungen vorliegen, sucht der Projekt-

leiter Lösungen, um die Vorgaben zu erfüllen. Sind die Abweichungen so groß, dass man

von unrealistischen Vorgaben reden muss, oder müssen Prioritäten zwischen Termin, Res-

sourcen und Kosten gesetzt werden, nimmt der Projektleiter mit dem Auftraggeber das

Gespräch auf.

Nach dem Führungskonzept des MbO (Management by Objectives, siehe Abschn.

4.1.13.4) muss dieser Prozess von Vorgabe (Top-down) und Abgleichung (Bottom-up)

zwangsläuﬁg stattﬁnden. Hat die ausführende Person kein Mitspracherecht (Bottom-up),

so wird es auch schwierig, Mitverantwortung für die Realisierung zu erwirken. In selbst-

organisierten Teams existieren heute andere Führungskonzepte als MbO.

2.4

Phase Konzept

179

Konzept

Realisierung

Einführung

Initialisierung

Beauftragung

+50%

+10%

-10%

-50%

Auftrag

1. Grobschätzung

2. Grobplanung

Schätz-Genauigkeit z.B. ähnliche Projekte schon durchgeführt

Schätz-Genauigkeit z.B. Pionierprojekte (Neuland)

Lastenheft

3. Detailplanung

Pﬂichtenheft

Abb. 2.51 Schätzgenauigkeit

Drei Vorgehensweisen sind für die Planung eines Projektes verbreitet:

Am Anfang des Projektes wird die ganze Projektdauer detailliert geplant

Am Anfang des Projektes wird das ganze Projekt grob geplant und am Ende einer

Phase die nächste Phase detailliert

Am Anfang des Projektes wird das ganze Projekt grob geplant und jeden Monat die

unmittelbare Zukunft (Lieferobjekte, Arbeitspakete und Tätigkeiten) sehr detailliert ge-

plant

Wenn große Erfahrung mit ähnlichen Projekten verfügbar ist oder Fixpreisangebote

abgegeben werden müssen, wird das ganze Projekt vollumfänglich und über seine ganze

Dauer detailliert geplant. Das bedeutet einen hohen Aufwand. Fehlen brauchbare Erfah-

rungswerte oder ist der Auftrag offen und völlig neu, wird in der Initialisierungsphase

lediglich eine Grobplanung für das ganze Projekt mit Grobschätzung des Aufwandes und

des Ressourcenbedarfs durchgeführt. Die Konzeptphase wird hingegen detailliert geplant.

Grobschätzungen sollen immer mit einer Bandbreite angeben werden, z. B. +40/20 %.

Dieses Vorgehen ist sehr efﬁzient und wird häuﬁg angewendet.

180

Methodik

Vorgaben

Detailplanung

– Termin und Ablaufplanung

– Kostenplanung

– Ressourceneinsatzplanung

– Ressourcenabgleich

Projektleitung

Arbeitsebene

Unternehmensleitung

Abstimmung bei Abweichung

Top-down: Vorgaben herunterbrechen

Bottom-up: Detailpläne konsolidieren

Abb. 2.52 Planung Top-down und Verdichtung Bottom-up

Bei großen Projekten ist es vorteilhaft, in mehreren Schritten zu planen, um das Pro-

jekt handhabbar zu machen. Erster Detaillierungsgrad: eine Ablauf- und Terminplanung

für Lieferobjekte und Arbeitspakete als Projektübersicht. In einem nächsten Schritt wird,

der Detaillierungsgrad erhöht bis auf Tätigkeiten, evtl. durch die Teilprojektleiter. Die

Planungstiefe soll an den Wissensstand angepasst sein und an die Konsequenzen, wenn

Abweichungen von der Planung entstehen.

Wenn der Innovationsgrad hoch ist und der Termin kritisch, dann wird der Detaillie-

rungsgrad der Lieferobjekte und Arbeitspakete schrittweise erhöht. Am Anfang wird das

Projekt in wenige grobe Lieferobjekte und Arbeitspakete unterteilt, dafür der ganze Pla-

nungshorizont erfasst. Steigt der Wissensstand, wird ein überblickbarer Teil des Projektes

weiter detailliert. In einem weiteren Schritt wird die unmittelbare Zukunft z. B. zwei Mo-

nate sehr detailliert geplant. Dieser Schritt wird jeden Monat wiederholt.

Bei großen Projekten besteht die Planung aus verschiedenen Schritten. Der Projektlei-

ter macht einen ersten Entwurf. Sind die Durchlaufzeiten zu lang oder nicht kompatibel

mit den Vorgaben, führt er eine erste Optimierung durch. Bei Ressourcenkonﬂikten wird

mit den Ressourcenverantwortlichen verhandelt und verbindlich vereinbart. Die Initial-

planung wird nun eingefroren, es erfolgt die Freigabe durch den Auftraggeber. Ändern

sich später die Rahmenbedingungen (z. B. Prioritäten der Unternehmensleitung), sind An-

2.4

Phase Konzept

181

5 Wochen

0.5

1.0

Kapazität (FTE)

…ergibt benötigte Kapazität

…ergibt benötigte Zeitdauer

feste Termine

ﬁxe Kapazität

10 Wochen

Zeit (Wochen)

Termintreue Planung

Das Arbeitspaket A (200

Arbeitsstunden) muss in

5 Wochen abgeschlossen

sein

Kapazitätstreue Planung

Das Arbeitspaket A (200

Arbeitsstunden) enthält eine

Kapazität von 0.5 FTE

Abb. 2.53 Ressourcen Histogramm: Termintreue vs. Kapazitätstreue Planung

passungen notwendig. Bei großen Änderungen kann eine Neuplanung der verbleibenden

Aufgaben notwendig werden (time-to-complete und cost-to-complete).

2.4.7.5

Termintreue und kapazitätstreue Planung

Je nach Zielsetzung erfolgt die Planung im Projekt termintreu oder kapazitätstreu, wie

Abb. 2.53 zeigt.

Hat der Endtermin einen hohen Stellenwert, wird termintreu geplant. Wie müssen wir

vorgehen? Welche Ressourcen müssen wir einsetzen? Welche Maßnahmen müssen ergrif-

fen werden, um diesen Termin sicherzustellen? Wie groß ist dann die Überlast und wie

lange dauert sie?

Haben die Kosten oder andere Projekte höhere Priorität, wird kapazitätstreu geplant?

Welcher Termin ergibt sich mit den verfügbaren Ressourcen?

Vorwärtsterminierung

Terminierung vom Projektstart bis zum Projektabschluss. Wird die Terminvorgabe über-

schritten, müssen Maßnahmen geprüft werden (mehr Ressourcen, Parallelisieren, Infra-

strukturverbesserung, externe Vergabe von Teilaufgaben, Ziel überprüfen usw.). Die Vor-

wärtsterminierung mit allfälliger Korrektur ist die meist verbreitete Vorgehensweise.

182

Methodik

Rückwärtsterminierung

Ausgehend vom verlangten Endtermin wird rückwärts terminiert, um die Frage zu be-

antworten: Wann müssen wir starten, damit das Terminziel erreicht wird? Würde der

Starttermin in der Vergangenheit liegen, kann die Zeit bis zum Plantermin im Verhältnis

der idealerweise benötigten Durchlaufzeiten aufgeteilt und als Vorgabe verwendet werden.

Anpassungen der Planung

In der Initialisierungsphase wurde eine Initialplanung erstellt und freigegeben. Bei den

Meilensteinen werden kritische Fragen gestellt und die Lage neu beurteilt: Treffen die

Annahmen, die bei der Initialplanung getroffen wurden, noch vollumfänglich zu? Sind

neue Rahmenbedingungen eingetreten? Bei Bedarf muss die bestehende Planung bezüg-

lich Ressourcen, Terminen, und Kosten aktualisiert werden. Das kann auch heißen, dass

neue Abmachungen zu treffen sind. Änderungen an der Projektplanung sind zu dokumen-

tieren und an die Betroffenen zu kommunizieren.

Treten absolut neue Rahmenbedingungen ein oder gewinnt man neue Erkenntnisse in

einem Umfang, dass die bisherige Planung nicht mehr als Basis für einen Plan/Ist-Ver-

gleich geeignet ist, weil sich Inhalt und Abgrenzung der Lieferobjekte und Arbeitspakete

seit der Initialplanung wesentlich geändert haben, dann ist beim momentanen Projektstand

ein Schnitt bei der Planung zu machen und ab dem Zeitpunkt eine Neuplanung zu erstellen

(time-to-complete und cost-to-complete).

Allfällige neue Ressourcenkonﬂikte, die durch die neue Situation entstanden sind, müs-

sen gelöst werden.

2.4.7.6

Wie detailliert soll eine Planung sein?

Der Detaillierungsgrad orientiert sich am Zweck. Die Planung soll so detailliert sein, dass

wir daraus die nötigen Maßnahmen ableiten und das Projekt zuverlässig überwachen und

steuern können. Die Planung muss mindestens so detailliert sein, wie wir später kontrol-

lieren möchten. Wenn die Kontrolle in kürzeren Abständen erfolgen soll, damit Probleme

frühzeitig angegangen werden können, dann müssen auch die Aufgaben feiner aufgelöst

werden. Die Qualität (Genauigkeit, Vollständigkeit) der Daten ist wichtiger als der De-

taillierungsgrad. Der Detaillierungsgrad sollte nicht höher als notwendig gewählt werden,

weil der Aufwand für Planung und Kontrolle rasch sehr groß wird.

2.4.7.7

Weitere Planungsvarianten: Target Costing, Design-to-Cost

In einem preissensitiven Umfeld sind die Kosten des Resultates aus dem Projekt, der

Dienstleitung (z. B. Arbeitsabläufe) oder des Produktes (Herstellkosten), wichtiger als

die „einmaligen“ Kosten des Projektes. 80 % der Produktkosten von neuen Produkten

und Dienstleistungen werden in der Deﬁnitions- und Entwicklungsphase festgelegt. Diese

können in späteren Projektphasen nur noch sehr beschränkt beeinﬂusst werden. Daraus

resultiert eine spezielle Verantwortung des Projektleiters und des Entwicklers für die Ein-

haltung der im Anforderungskatalog vereinbarten Kostenziele.

2.4

Phase Konzept

183

Bei der Zielkostendeﬁnition wird ein Maximalwert festgelegt, wie viel die Herstel-

lungskosten des Produktes betragen dürfen (Target Costing) und als verbindlicher Wert in

den Zielsetzungen aufgenommen. Zu berücksichtigende Kriterien sind:

Wie viel ist der Markt bereit für diese Leistung zu bezahlen? Welche Stückzahlen kön-

nen wir absetzen, zu welchen Konditionen?

Wo stehen unsere Mitbewerber bezüglich Preisen und Marktanteilen?

Welche Zielkosten und Stückzahlen legen wir unserer Wirtschaftlichkeitsberechnung

zugrunde?

Wie ist unsere Kostenstruktur, ohne und mit Maßnahmen?

Dieser Zielkostenwert wird aufgeschlüsselt auf die einzelnen Teilsysteme, Baugruppen

oder auf die an der Dienstleistung beteiligten Stellen. So weiß jeder Beteiligte, welchen

Anteil der Produktkosten seine Arbeit oder sein Teilsystem verursachen darf. Der Projekt-

leiter überwacht die Einhaltung dieses Herstellkostenbudgets.

Aus der Sicht des Kunden und des Benutzers sind nicht nur die Anschaffungskosten

von Bedeutung, sondern ebenfalls die bei ihm während der Nutzung anfallenden Betriebs-

kosten, Kosten für Reparaturen, Unterhalt, Ausbildung, Entsorgung oder andere Folgekos-

ten. Er ist an niedrigen Gesamtkosten (life-cycle-costs) interessiert, die durch die Investi-

tion über den ganzen Lebenszyklus verursacht werden. Der Projektleiter sollte Lösungen

bevorzugen, die auf niedrige Gesamtkosten zielen, solange dadurch die Herstellkosten und

Projektkosten nicht übermäßig steigen, außer der Kunde honoriert dies.

Bei Produkten, die hergestellt (dupliziert) werden, sollen Projektleiter und Entwickler

das optimale Verhältnis von Projektkosten (Einmalkosten) zu Produktkosten (Wiederhol-

kosten) wählen, aus dem die niedrigsten Gesamtkosten für die prognostizierte Stückzahl

resultieren. Projektkosten sind Einmalkosten. Herstellkosten fallen pro hergestelltes Ex-

emplar des Produktes an.

Wenn von einem Produkt die Herstellung großer Stückzahlen beabsichtigt ist, weil der

Markt dafür aufnahmefähig ist, kann im Projekt ein größerer Aufwand für die Entwick-

lung investiert werden, um kostengünstigere Lösungen zu ﬁnden und eine rationellere

Herstellung zu erreichen. Dabei steigen aber die Projektkosten. Im Gegensatz dazu ist der

Anteil der Projektkosten pro Produkt höher bei Einzelanlagen oder wenn nur eine klei-

ne Stückzahl des Produktes hergestellt wird. Hier sind die Einmalkosten des Projektes

niedrig zu halten. Bei Dienstleistungen oder Arbeitsabläufen können diese Überlegungen

genauso angewendet werden. Es gilt, das optimale Verhältnis zwischen den Einmalkos-

ten der Investition und den Wiederholkosten des Arbeitsaufwandes zu ﬁnden. Beispiele:

Lagerbewirtschaftung, Krankenpﬂege.

Die Break-even Analyse hilft auf anschauliche Art, diesen Zusammenhang aufzuzeigen

und die Auswirkungen zu erkennen, falls die geplante Stückzahl nicht am Markt abgesetzt

werden kann, siehe dazu Abb. 2.54.

184

Methodik

Variable Kosten 1

Kosten

Stückzahl

Variable Kosten 2

Break-even

Fixe Kosten 2

Fixe Kosten 1

Abb. 2.54 Break-even-Analyse

2.4.8

Ressourceneinsatzplan und Ressourcenabstimmung

Aus dem Ablauf- und Terminplan lässt sich in der klassischen Vorgehensweise die Res-

sourceneinsatzplanung ableiten. Eine Voraussetzung dafür ist die Abstimmung der benö-

tigten Ressourcen im Projekt mit den verfügbaren Ressourcen in der Linie. Versäumnisse

in der Ressourcenabstimmung sind in der Praxis häuﬁg Ursachen für Probleme in an-

spruchsvollen Multiprojektumgebungen.

2.4.8.1

Ressourceneinsatzplanung im Projekt: Linie und Projektleiter als

Partner

Die Projektplanung wird durch den Projektleiter verantwortet. Mit der Ablaufplanung und

Terminierung plant er, was zu tun ist und wann es zu tun ist (Abb. 2.55). Zum Zeitpunkt

der Planung ist die Verfügbarkeit der Ressourcen noch nicht sichergestellt.

Liegt der Ablaufplan vor, ist der Ressourceneinsatz zu planen. Der Ressourceneinsatz-

plan eines Projektes enthält die Plandaten mindestens aller Engpassressourcen, die am

Projekt beteiligt sind. Der Projektleiter nimmt die Ressourceneinsatzplanung zusammen

mit den Führungskräften der Linie oder einem zugeordneten Ressourcen-Abstimmungs-

verantwortlichen wahr.

2.4

Phase Konzept

185

Anzahl Personen

Zeit

Abb. 2.55 Ressourceneinsatzplan eines Projektes

2.4.8.2

Ressourcenabstimmung im Multiprojektmanagement

Für die Ressourcenplanung sind Projektleiter und Linienverantwortliche aufeinander an-

gewiesen. Der Projektleiter meldet seine Ressourcenbedürfnisse und Wünsche den Li-

nienverantwortlichen. Wenn die benötigten Ressourcen verfügbar sind, werden diese ihm

zugesagt und verbindlich reserviert. Voraussetzung für eine verbindliche Zusage durch die

Linienverantwortlichen ist, dass diese eine aktualisierte Ressourcen-Einsatzplanung über

alle Projekte durchführen (siehe Abschn. 2.7.1.6). Treten Ressourcenkonﬂikte auf, weil

mehrere Projekte gleichzeitig auf dieselbe Ressource zugreifen möchten, müssen Pro-

jektleiter und Ressourcenverantwortliche gemeinsam Lösungen ﬁnden und Abmachungen

treffen.

Günstig ist, wenn der Ressourcenverantwortliche (oft der Linienverantwortliche) sich

bewusst ist, dass er eine Dienstleistungsverantwortung in seinem Fachbereich zugunsten

der Projekte hat. Hilfreich ist aber auch, wenn der Projektleiter sich bewusst ist, dass er

nicht immer genau den Spezialisten zu dem Zeitpunkt haben kann, der ihm am liebsten

wäre, und dass er darum eine gewisse Flexibilität an den Tag legen muss. Dann sind die

Voraussetzungen günstig für partnerschaftliche Verhandlungen zwischen Projektleitern

und Ressourcenverantwortlichen. Abb. 2.56 zeigt den Ressourcenabgleich verschiedener

Projekte mit der Linie.

186

Methodik

Linien-Management, Ressourcen-Manager

Ressourcen-Abgleich

Projekt

A 21

Ressourcen-

Bedarf

Projekt

T 05

Ressourcen-

Bedarf

Projekt

D 17

Ressourcen-

Bedarf

Projekt

F 34

Ressourcen-

Bedarf

Einsatzplan: Markus Müller

Auslastung %

Zeit

150

100

Grundlast

A 21

F 34

T 05

Abb. 2.56 Multiprojektplanung

Abb. 2.57 zeigt die Auslastung eines Mitarbeiters durch Grundlast und mehrere Pro-

jekte über den Zeitverlauf.

Entspricht der resultierende Termin nicht den Vorgaben, ist es Aufgabe des Projektlei-

ters, Maßnahmen zu prüfen und Korrekturen vorzunehmen. Mögliche Optimierungsmaß-

nahmen für den Fall, dass das Planresultat einen zu späten Endtermin ergibt, sind:

Verschiebungen innerhalb der Pufferzeit;

vermehrte Parallelisierung (Zunächst auf dem kritischen Pfad nach derjenigen Tätigkeit

mit dem größten Weitergliederungs-Potenzial suchen. Meistens ist dies eine Tätigkeit

mit langer Dauer. Nun die Abhängigkeiten zu den Folgetätigkeiten überprüfen mit dem

Zweck, die abhängigen Vorgänge vorzuziehen, damit Folgetätigkeiten früher beginnen

können. Die untersuchte Tätigkeit ist dadurch in zwei oder mehrere Teile zu unterteilen

und die Tätigkeitsliste zu erweitern);

Einsatz zusätzlicher verfügbarer Ressourcen;

Festlegung von Projektprioritäten durch die Geschäftsleitung, wodurch einzelne Pro-

jekte zu Ungunsten von anderen bevorzugt werden;

Auslagerung (Outsourcing) von geeigneten Tätigkeiten bzw. Arbeitspaketen und

Unterscheidung zwischen Grundfunktionen und erst später in Updates zu realisieren-

den Optionen.

2.4

Phase Konzept

187

Zeit

Auslastung

100%

150%

50%

Projekt F 34

Projekt T 05

Projekt A 21

Projekt D 17

Grundlast

Abb. 2.57 Auslastung eines Projektmitarbeiters

Falls sich die zeitliche Vorgabe oder der Aufwand als unrealistisch erweist, einige sich

der Projektleiter mit dem Auftraggeber.

2.4.9

Kostenplan

Mit der Kostenplanung werden alle im Projekt eingesetzten Mittel erfasst, welche einen

Kostenaufwand oder direkte Geldausgaben verursachen, wie z. B.:

sämtliche internen und externen Projektmitarbeiter inkl. Projektleiter

temporäre Benützung oder Miete von Spezialeinrichtungen wie Räume, Maschinen,

Instrumente, und ICT

externe Investitionen für Anschaffungen

übrige direkte Kosten wie Spesen, Gebühren und Versicherungen

Der zeitliche Anfall der Kosten hängt vom Einsatz der Ressourcen ab. Dabei werden

drei Arten unterschieden:

188

Methodik

Nr. Tägkeit

Dauer

FTE

Aufwand Tagessatz

Externe

Interne

Tage

€/Tag

Kosten €

3 Tägkeit A

0.50

1'200

18'000

4 Tägkeit B

1.40

1'500

10'500

5 Tägkeit D

1.00

1'200

12'000

6 Tägkeit E

1.40

1'500

31'500

Inveson

95'000

7 Tägkeit C

1.50

1'200

18'000

8 Tägkeit F

0.80

1'833

22'000

9 Tägkeit G

1.60

1'500

12'000

10 Vorbereitung MS

1.00

1'800

9'000

11 MS-Entscheid

Subtotal

117'000

111'000

FTE = Full Time Equivalent

Projektkosten Total

228'000

Abb. 2.58 Angaben für die Kostenplanung

Einsatz und Kostenanfall über die Tätigkeitsdauer gleichmäßig verteilt durch Verrech-

nung mit entsprechendem Kostensatz

Einsatz oder Kostenanfall am Anfang der Tätigkeit, beispielsweise als Vorinvestition

in später notwendige Anschaffungen

Einsatz oder Kostenanfall am Ende der Tätigkeit durch Fakturierung einer Leistung

oder Anschaffung nach Auslieferung

Eine Kostenplanung und Budgetierung im Projekt dient folgenden Zwecken:

Das Unternehmen als Kapitalgeber hat eine Grundlage für die Bereitstellung der ﬁnan-

ziellen Mittel und kann seine Liquidität planen

Der Auftraggeber hat eine Entscheidungsgrundlage bei Meilensteinentscheiden

Der Projektleiter verfügt über ein operatives Überwachungs- und Kontrollinstrument

Zur Ermittlung der Projektkosten werden die Kosten jeder einzelnen Tätigkeit, bzw. je-

des einzelnen Ressourcenpostens, berechnet und über die gesamte Projektdauer summiert,

siehe Abb. 2.58.

Überlagert man die budgetierten Daten aus der Ressourcen- und Kostenplanung mit

der Terminplanung, entsteht die Kostenkurve. Sie stellt den Verlauf der kumulierten Ge-

samtkosten des Projektes über die Projektlaufzeit dar.

Die in Abb. 2.59 dargestellte Kostenkurve ist ein zweckmäßiges Instrument zur Ab-

schätzung von:

Periodenkosten bei der Freigabe der einzelnen Projektphasen

Budgetbeträgen für die individuellen Geschäftsjahre zur Bereitstellung der Mittel

Liquidität bei den erforderlichen Investitionen

Sie ist Basis für einen Plan/Ist-Kostenvergleich.

2.4

Phase Konzept

189

1'000 € (pro Woche)

1'000 € (kumulativ)

Zeit

100

150

100

250

200

Interne Kosten

Externe Kosten

Gesamtkosten (kumulativ)

Abb. 2.59 Kostenkurve

2.4.10

Information, Kommunikation und Dokumentation

Information und Kommunikation ﬁnden in Projekten immer in irgendeiner Form statt.

Die Frage ist dabei: „läuft“ sie zufällig, oder wird sie bewusst gestaltet? Im ersten Fall

wird ein hohes Risiko eingegangen: Projektbeteiligte sind nicht oder nicht zeitgerecht mit

den nötigen Informationen versorgt. Dokumente werden nicht abgelegt oder gefunden.

Anspruchsgruppen fühlen sich nicht einbezogen und leisten Widerstand. Gerüchte breiten

sich aus.

Oft werden Information und Kommunikation in Projekten als notwendiges Übel ange-

sehen oder schlicht vergessen, denn zu sehr ist die Projektleitung oder das Projektteam mit

den inhaltlichen Fragestellungen beschäftigt. Die Projektleitung sollte sich jedoch bewusst

sein, dass gute Information und Kommunikation wesentliche Faktoren zum Projekterfolg

sind und einen Erfolgsfaktor im Stakeholder Management darstellen (Abschn. 2.3.5). In

agilen Projekten erfolgt über das Daily Standup Meeting (siehe Abschn. 2.5.3) täglich ein

strukturierter Informationsaustausch.

190

Methodik

Information und Kommunikation werden nach innen und nach außen adressiert.

Nach innen zum Kreis der Projektbeteiligten: ein zielorientiertes Handeln erfordert

für die Projektbeteiligten ein hohes Maß an Transparenz und umfassender Information.

Die Fakten und Dokumente wie Pﬂichtenhefte, Terminpläne, Verträge müssen für alle

Teammitglieder zugänglich sein.

Nach außen zu Kunden, Nutzern, Interessengruppen und der Öffentlichkeit: wäh-

rend des Projektes gilt es vor allem, Vertrauen aufzubauen, Akzeptanz und Unter-

stützung zu erhalten. Gerüchte werden durch Fakten ersetzt und damit die negativen

Einﬂüsse auf das Projekt reduziert.

Nach dem Projektabschluss in der Nutzungsphase müssen Projektdokumentationen zur

Sicherstellung des Betriebes zur Verfügung stehen.

Information und Kommunikation werden im Projekt und in der Linie unterschiedlich

gehandhabt. In der Linienhierarchie wird über vordeﬁnierte Berichtswege kommuniziert.

In Projekten mit eher kleinen Teams, eignen sich direkte, möglichst kurze Informati-

onswege besser. Sie erlauben eine ﬂexible und rasche Entscheidungsﬁndung sowie eine

bessere Koordination.

2.4.10.1

Grundsätze der Information und Kommunikation

Projekte bringen Veränderungen, Ängste, Phantasien, Frust. Diese können über eine of-

fene Kommunikation „verarbeitet“ werden. Üblicherweise wird zu wenig oder zu spät

informiert. Gerade in heiklen Projekten merken die potenziellen Betroffenen sehr bald,

dass „etwas läuft“. So entstehen dann oft Gerüchte, die verunsichern, diffuse Befürchtun-

gen aufkommen lassen und dem Projekt sehr schaden können. Daher empﬁehlt es sich in

den meisten Fällen, frühzeitig zu informieren. Natürlich kann dann noch nichts über Re-

sultate ausgesagt werden. Aber es kann informiert werden, was läuft, wer dran ist, was der

Projektgegenstand, die Vision oder das Ziel ist, und wann ein erstes Ergebnis zu erwarten

ist.

Man kann auch über Prozesse, nicht nur über Inhalte und Lösungen informieren. Ter-

minverzögerungen und Schwierigkeiten können nach außen transparent gemacht werden.

Das fördert jedenfalls mehr das Vertrauen, als wenn immer nur in den positivsten Tönen

oder gar nicht informiert wird.

Falsch aufbereitete Information kann mehr schaden als nützen. Empfänger haben meis-

tens andere Interessenschwerpunkte, Fragen, Verständnisse oder „Brillen“ als die Projekt-

beteiligten. Diese geben sich meistens kaum Mühe, sich in die Lage der Kunden, Benutzer

oder Betroffenen zu versetzen. Nicht von ungefähr engagieren große Projekte oft Kommu-

nikationsbeauftragte, die eine gewisse Außensicht haben und die Sprache und Interessen

der Empfänger besser erkennen können.

2.4

Phase Konzept

191

2.4.10.2

Umfang eines Informations- und Kommunikationssystems

Das ganze System der Projektinformation und -kommunikation kann wie folgt gegliedert

werden:

Mündliche Kommunikation in Gesprächen, Sitzungen, Problembearbeitungen und

inhaltlicher Zusammenarbeit an Workshops

Berichtswesen: Protokolle, Fortschrittsberichte, Änderungen usw.

Projekt-Dokumentation: Projekthandbuch, projektbezogene Ablagen, inhaltliche Do-

kumente wie Konzepte oder Anleitungen

Projektmarketing zur Schaffung von Vertrauen und Akzeptanz durch Informations-

veranstaltungen, ﬁrmeninterne Plakate, Referate, Lobbying usw.

Collaboration-Tools, um Pläne, Dokumente, Backlogs usw. gemeinsam zu bearbeiten

und sich auszutauschen.

In einem Projekt müssen nicht alle Komponenten gleichwertig zum Tragen kommen.

So kann in einem Forschungsprojekt das Tagebuch für fortlaufende Datenaufnahmen

wichtig sein, während kaum Marketing betrieben werden muss. In einem Change-Projekt

hingegen sind die mündliche Kommunikation sowie das Marketing wichtig.

Da das Kommunikationskonzept bei jedem Projekt praktisch immer wieder neu erfun-

den werden muss, lohnt es sich bei Standardprojekten, in Projektmanagementrichtlinien

die entsprechenden Berichtswege, Checklisten, Dokumentationsprinzipien zu standardi-

sieren und entsprechende Vorlagen zur Verfügung zu stellen.

Die Gesamtheit der Information und Kommunikation kann in einer Kommunikations-

matrix dargestellt werden, wie in Tab. 2.37 aufgezeigt.

Tab. 2.37 Kommunikationsmatrix

Charakteristik

Informationsart

Verantwortlicher

Berichterstatter

Verteiler/Teilnehmer

Termin/Frequenz

Mündliche Informationen

Projektstand

(Präsentation)

Product Owner/

Projektleiter

Stakeholder

Nach Bedarf

Projektausschuss-Sit-

zung/Sprint Review

Team/Projektleiter

Projektausschuss,

interne Stakeholder

Nach Bedarf/bei

Sprintende

Projektbesprechung/

Daily Standup Meeting

Scrum Master/

Projektleiter

Projektteam

Wöchentlich/Täglich

Schriftliche Informationen

Projektstatusbericht

Projektleiter/Product

Owner

Projektausschuss,

Portfoliomanagement,

interne Stakeholder

Monatlich/

Quartalsweise

Phasenabschlussbericht/

Projektabschlussbericht

Projektleiter/Product

Owner

Projektausschuss

Nach Bedarf

192

Methodik

Zur Erstellung der Kommunikationsmatrix können die so genannten „W-Fragen“ hilf-

reich sein:

Wer ist der Absender? Wer informiert? Oft kann es einen beträchtlichen Unterschied

machen, ob die Projektleitung oder der CEO informiert!

Wen braucht es für das Projekt? Wer sind die Empfänger?

Was ist der Gegenstand der Information? Welches Ziel wird damit verfolgt? Welches

ist die Botschaft?

Wann und in welcher Periodizität wird informiert? Wird die Information angekündigt?

Wie wird informiert, in welcher Form, mit welchen Medien? z. B. Papier, Mail, An-

schlagbrett, Scrum Board, Hauszeitung usw. Mit welcher Methode wird informiert?

Wie soll Feedback eingeholt werden?

Wo und in welchem Rahmen soll die Information vermittelt, die Auseinandersetzung

geführt werden?

Wie weit soll die Information zugänglich sein und als Arbeitsplattform der räumlich

getrennten Projektmitarbeiter dienen, z. B. Homepage, Intranet?

2.4.11

Qualitätsmanagement

Mit dem Qualitätsmanagement wird im Projektverlauf sichergestellt, dass die erstellten

Ergebnisse der geforderten Qualität entsprechen. Dazu ist im Projekt ein entsprechender

Prozess zu etablieren. Bei allen Projektmitarbeitern ist zudem ein Verständnis für Qualität

zu schaffen.

Qualität ist relativ und abhängig von den Anforderungen des Auftraggebers, bezie-

hungsweise des Kunden. Die Ansprüche an das zu erreichende Qualitätsniveau können

sehr stark variieren. Es geht im Projekt nicht darum, ein möglichst hohes Qualitätsniveau

zu erreichen, sondern das geforderte Niveau. Aus den Anforderungen lassen sich für das

Projekt die Qualitätsziele ableiten und festlegen.

In der Qualitätssicherung wird oft zwischen Prüfen und Testen unterschieden:

Prüfen: Dokumente und die Einhaltung vereinbarter Prozesse und Aufgaben inhaltlich

und formell überprüfen.

Testen: Die Erfüllung der Anforderungen und die Anwendbarkeit der Prozesse am

entwickelten Produkt, System oder an der Anlage überprüfen.

Prüfen

Zur Prüfung eignen sich Verfahren wie Vernehmlassungen, Audits oder Reviews. Das

heißt die Überprüfung ﬁndet durch betroffene Stakeholder oder Experten statt. Ziel ist es

zu überprüfen, ob die geforderte Qualität erreicht wurde oder ob ein Konzept oder eine

Architekturskizze dazu dient, die gesetzten Projektziele zu erreichen. Gefundene Mängel

oder Missstände werden in einer Befundliste oder in einem Prüfprotokoll festgehalten und

2.4

Phase Konzept

193

dem Projektteam zur weiteren Bearbeitung zurückgegeben. Vielfach gibt der Prüfer zum

Befund auch eine Empfehlung ab, wie der Befund am besten zu beheben ist.

Testen

Vor dem Testen empﬁehlt es sich, ein Testkonzept zu erarbeiten. In einem Testkonzept

werden die Testobjekte, Testmethoden und die Testinfrastruktur beschrieben. Es empﬁehlt

sich auch, Testziele und die Testorganisation festzuhalten.

Als Ergänzung zum Testkonzept werden in der Praxis Testfälle und ein Testplan er-

arbeitet: Wer testet wann was? Die Testfälle können mittels Ofﬁce Anwendungen oder

in einer umfassenden Testsuite (Software) aufgebaut werden. Der Einsatz einer Testsuite

hat den Vorteil, dass die gefundenen Fehler erfasst werden können und diese bis zur voll-

ständigen Behebung und zu neuerlichem Test getrackt werden. Mit einer Testsuite können

auch Auswertungen zum Testfortschritt und Testerfolg gemacht werden.

Mit dem Durchführen der Tests wird die Erfüllung der gestellten Anforderungen über-

prüft. Gefundene Fehler werden erfasst. Zum Abschluss einer Testsequenz wird ein Test-

protokoll erstellt.

Qualitätsmanagementplan

Qualitätsplanung heißt, all jene Prüf- und Test-Maßnahmen festzulegen, die aufgrund der

Vorschriften, der guten Praxis und der Qualitätsanforderungen des Unternehmens not-

wendig sind, um die Qualitätsziele des Projektes oder des Produktes sicherzustellen. Im

Qualitätsplan werden alle festgelegten und wirtschaftlich vertretbaren Maßnahmen auf-

gelistet, bis wann sie durchgeführt werden und wer dafür verantwortlich ist. In großen

Projekten werden diese Maßnahmen in einem eigenständigen Qualitätsplan festgehalten.

In kleinen Projekten kann diese Information in ein anderes Planungsdokument integriert

werden, z. B. in den Ablauf- und Terminplan.

Beispiele für Maßnahmen im Qualitätsplan

Prüfung von Dokumenten

Test des fertigen Produktes, Zwischenprüfungen

Erprobung in der Betriebsumgebung beim Kunden, Qualiﬁkationstest, Konformitäts-

test, Homologierung, klinische Tests, Zulassungsprüfungen

Design Reviews, Design-Veriﬁzierung, Design-Validierung

Value Engineering, Wertanalyse, Zuverlässigkeitsanalyse

Spezialprüfungen: Integrationstest, Sicherheitsprüfungen

Vorbehandlungen (Dauertest, Burn-In usw.)

Umwelttests, Klimatest, Schütteltest, Fall-Test

Korrosionsprüfung, chemische Rückstände, Brennbarkeit

elektromagnetische Verträglichkeit, Störstrahlung

Prototyp, Nullserie

194

Methodik

Aus Aufwandgründen dürfen nur diejenigen Maßnahmen festgelegt und durchgeführt

werden, die von der Sache her notwendig und wirtschaftlich vertretbar sind, deren Wirk-

samkeit erwiesen ist oder die vom Kunden verlangt und honoriert werden.

2.4.12

Checkliste Abschluss Konzeptphase

Agile und klassische Vorgehensweise:

Bestehen Änderungen gegenüber der Initialisierung bezüglich Zielsetzung, Sys-

temgrenzen und -gestaltung? Sind diese berechtigt? Welche Auswirkungen

ergeben sich daraus?

Wie wurden die gewünschten Änderungen im Projektplan berücksichtigt?

Sind die Schätzungen zu Mengen, Häuﬁgkeiten und Terminen so konkret, dass

sie umgesetzt werden können?

Wurde die Bewertung der Risiken mit den Erkenntnissen der Konzeptphase

überprüft? Wurden die notwendigen Maßnahmen festgelegt und die Aktionen

vorbereitet?

Ist die Wirtschaftlichkeit des Projektes zum heutigen Zeitpunkt noch erwiesen?

Wie zeigt sich die Gesamtwirtschaftlichkeit des Projektes?

Ist das Vorgehen der Realisierungsphase mit allen Beteiligten abgestimmt?

Sind Handlungskompetenzen und Verantwortlichkeiten den Erfordernissen ent-

sprechend geregelt?

Wie werden die Richtlinien für Projektcontrolling und -Reporting eingehalten?

Sind die Planungsunterlagen vollständig, oder ist mindestens die Vervollständi-

gung konkret geplant?

Gibt es ein Konzept, wer wen wie über das Projekt informiert?

Besteht eine Vorstellung darüber, in welcher Form das Projekt dokumentiert wer-

den soll?

Steht fest, wer die künftige Lösung pﬂegen wird? Kennen die Zuständigen den

Zeitpunkt, wann sie die Verantwortung für das Ergebnis des Projektes überneh-

men werden?

Speziﬁsche Punkte der klassischen Vorgehensweise

Wurden Lösungsvarianten entwickelt und bewertet?

Sind alle möglichen Lösungsansätze identiﬁziert?

Sind die Vor- und Nachteile der Varianten und deren Risiken klar ersichtlich?

Wurde eine Variante mit ausführungsreifen Plänen ausgewählt?

2.5

Phase Realisierung

195

Wurde die gewählte Lösung mit den notwendigen Lösungskonzepten im Detail

ausgearbeitet?

Wurden Aufwand, Ressourcen und Termine vollständig und realistisch im Detail

geplant? Wurde ein Plausibilitätstest durchgeführt?

Sind die ﬁnanziellen Mittel und die Liquidität über die ganze Dauer des Projektes

gesichert?

Ist die Verfügbarkeit der benötigten ﬁnanziellen und personellen Mittel zugesi-

chert?

Ist das notwendige Know-how verfügbar? Sind die entsprechenden Ressourcen

zugesichert?

Speziﬁsche Punkte der agilen Vorgehensweise

Wurden das Produktkonzept geklärt und die Vision deﬁniert?

Wurde eine erste Version des Product Backlogs ausgearbeitet?

Sind die Einträge im Product Backlog priorisiert und geschätzt?

Wurde der Releaseplan deﬁniert?

Sind die Einträge priorisiert?

2.5

Phase Realisierung

In der klassischen Vorgehensweise werden in der Realisierungsphase die Pläne aus der

Konzeptphase verwirklicht. Eine umfassende laufende Überprüfung und Steuerung

hilft, das Projekt auf Kurs zu halten und das gewünschte Ziel zu erreichen.

In der agilen Vorgehensweise entfällt das externe Überwachen der Pläne. Durch die

Selbstorganisation der Teams erfolgt die Steuerung innerhalb des Teams. Die Detailkon-

zeption wird für jeden Sprint gemacht und direkt umgesetzt. Dies ermöglicht es, ﬂexibel

auf geänderte Wünsche oder Rahmenbedingungen einzugehen.

2.5.1

Worauf kommt es in der Phase Realisierung an?

Schritte dieser Phase

Tab. 2.38 zeigt die wichtigsten Schritte in der agilen und klassischen Vorgehensweise für

die Realisierungsphase.

196

Methodik

Tab. 2.38 Schritte der Phase Realisierung

Agile Vorgehensweise

Klassische Vorgehensweise

Wichtigste Schritte

– Lösung konkretisieren und iterativ

realisieren

– Laufende Realisierung von Ver-

besserungen am Produkt und in

der Zusammenarbeit des Teams

– Ausbildung der künftigen Benut-

zer planen

– Projektmarketing betreiben, d. h.

Beteiligte und externe Stellen

(z. B. Kunden) informieren

– Sachmittel, personelle und ﬁnan-

zielle Mittel bereitstellen

– Lösung herstellen und testen

– Ausbildung der künftigen Benut-

zer planen

– Projektablauf steuern

– Plan/Ist-Vergleiche durchführen

(ﬁnanzielle Führung, Controlling)

– Abweichungen kommunizieren

– Projektmarketing betreiben, d. h.

Beteiligte und externe Stellen

(z. B. Kunden) informieren

Worauf ist in der

Realisierungsphase

besonders zu

achten?

– Fokus auf die zu realisierende Lösung aufrecht halten. Verzettelungen

vermeiden.

– In der agilen Vorgehensweise sind das dauernde Lernen und das sich

Verbessern institutionalisiert. Erfolgreiche Projektleiter wenden die

Prinzipien der laufenden Verbesserungen auch in der klassischen Vor-

gehensweise konsequent an.

Ergebnisse der Realisierungsphase

In der Realisierungsphase sind die Ergebnisse gemäß Tab. 2.39 von Bedeutung.

Mensch und Team

In der Realisierungsphase kann sich die Zusammensetzung des Teams nochmals verän-

dern, womit alle in der Konzeptphase aufgeführten Aspekte wieder relevant sein können

(Abschn. 2.4.1). Zudem ist bereits die Einführung zu planen.

Folgende Maßnahmen und Kompetenzen sind wichtig:

Dynamik in Teams (Abschn. 4.2): Häuﬁg treten in dieser Phase Konﬂikte und Wi-

derstände im Team auf. Das Team kann aus einem „Performing“ zurückfallen in ein

„Storming“. Die Arbeit am System (Abschn. 1.5.2) sowie das Konﬂiktmanagement

(Abschn. 4.4) bleiben wichtige Aspekte für die Projektverantwortlichen.

Projektteams sind darauf angewiesen, ihre Vorgehensweisen dauernd anzupassen und

schnell zu lernen. Dafür ist es essentiell, konstruktives Feedback geben zu können

(Abschn. 3.9.7.3) sowie die Fragetechniken zu beherrschen (Abschn. 3.9.8)

Konstruktives Feedback steht wiederum auf dem Fundament einer Kommunikations-

kultur, die basiert auf einem Menschenbild des „Nicht-trivialen Systems“ (Abschn.

1.6.2), der Selektiven Wahrnehmung (Abschn. 3.3.5) und damit auch der Unterschei-

dung von Wertung und Wirkung.

Erfolgsfaktoren der Zusammenarbeit (Abschn. 4.1.14.1): Projektteams, die in ihren

Teamrollen ausgeglichen sind, sind leistungsfähiger als diejenigen mit dem höchsten

2.5

Phase Realisierung

197

Tab. 2.39 Ergebnisse der Realisierungsphase

Agile Vorgehensweise

Klassische Vorgehensweise

Grundsatz

Die Lösung bzw. das System werden gebaut und getestet. Damit das Projekt

abgeschlossen werden kann, müssen am Schluss der Realisierungsphase die

folgenden Ziele erreicht sein:

– Das System, das Produkt, die Dienstleistung ist beschafft bzw. erstellt

– Die Lösung ist getestet und abgenommen

– Die Ergebnisse werden genutzt, sobald die Benutzer dazu befähigt sind

Prozess-

orientierte

Ergebnisse

Die iterative Entwicklung richtet

sich nach den aktuellen Prioritäten.

Die zu realisierende Lösung wird

laufend den neuesten Bedürfnissen

angepasst.

– Aktuelles Product Backlog

– Sprint Planungen

– Angebote, Verträge,

Abrechnungen

– Phasen-/Review-Bericht

Die Projektleitung stellt das Con-

trolling in den Vordergrund: Sie

kommuniziert den Projektstand im Ver-

gleich zur Planung sowie die geplanten

Änderungen (siehe Abschn. 2.5.8). Da

es in dieser Phase oft viele Projekt-

beteiligte gibt, ist eine systematische

Information und Kommunikation unum-

gänglich (siehe Abschn. 2.4.10).

– Projektfortschrittsberichte

– Realisierungspläne Änderungsdoku-

mente

– Angebote, Verträge, Abrechnungen

– Qualitätsbeurteilung

– Phasen-/Review-Bericht

Inhaltsorientierte

Ergebnisse

– Implementierte Teillösungen

(Inkremente)

– Ergebnisse aus dem Sprint

Review

– Realisierte Ergebnisse

– Testberichte

– Dokumente für die Einführung und

Instruktion im Einführungskonzept

zusammengefasst

Intellekt. Es braucht eine Balance zwischen den Teamrollen. Damit sich diese Balan-

ce in höhere Leistungsfähigkeit umwandeln kann, sind hohe Kompetenzen gefragt in

Bezug auf die persönliche Kommunikation (Abschn. 3.9), das Konﬂiktmanagement

(Abschn. 4.4) oder die Verhandlungsführung (Abschn. 4.3)

Jedes Projekt bewirkt kleinere oder größere Veränderungen. Projektverantwortliche

sind immer auch „Change-Agents“. Veränderungen wiederum bewirken Widerstand.

Der Planung der Einführung und damit dem Umgang mit Veränderung und Widerstand

(Abschn. 4.5) ist nun Beachtung zu schenken.

2.5.2

Sprintplanung/Sprint Backlog

Die Umsetzung im agilen Verfahren nach Scrum ﬁndet in Iterationen statt. Diese Itera-

tionen werden Sprints genannt. Je nach Projektart liegt die Dauer eines Sprints zwischen

zwei Wochen und zwei Monaten. In der Praxis dauern die Sprints am häuﬁgsten drei

198

Methodik

oder vier Wochen. Ein Sprint sollte so geplant werden, dass die Resultate entspannt und

fokussiert erreicht werden können. Das Team soll nach der Durchführung eines Sprints

immer noch frisch genug sein, um im Anschluss den Folgesprint entspannt und fokussiert

angehen zu können.

Damit die Sprintplanung efﬁzient und ohne Reibungsverluste durchgeführt werden

kann, muss das Planungsmeeting vorbereitet werden:

Identiﬁkation und Deﬁnition des Sprint-Ziels durch den Product Owner. Das Sprint-

Ziel soll realistisch und prägnant sein und aufzeigen, was das im Sprint zu erreichende

Ergebnis ist.

Auswahl und Aufbereitung der Anforderungen (User Stories) aus dem Product

Backlog durch den Product Owner. Die Auswahl soll sich nach der Priorisierung und

dem Releaseplan richten und dem Entwicklungsteam genügende Auswahlmöglichkei-

ten bieten. Die Anforderungen sollten auch so detailliert deﬁniert sein, dass mehrere

davon in einem Sprint umgesetzt werden können.

Wenn möglich sollte die Umsetzung der Anforderungen geschätzt sein.

Die Anforderungen sollten durch den Product Owner priorisiert sein.

Das Entwicklungsteam identiﬁziert die im Sprint zur Verfügung stehende Teamkapa-

zität.

Aus dem Product Backlog wird während der Sprintplanungssitzung der Sprint Back-

log erstellt. An der Sprint Planungssitzung nehmen der Product Owner, das Team und

der Scrum Master teil. Der Product Owner erklärt dem Team, was das Sprint-Ziel ist und

welche Anforderungen (User Stories) aus dem Product Backlog im nächsten Sprint um-

gesetzt werden sollen. Zu der Zielsetzung und den ausgewählten Anforderungen wird ein

gemeinsames Verständnis etabliert. Je nach Verlauf der Diskussion müssen Sprint-Ziel

und die Auswahl der Anforderungen angepasst werden, so dass ein gemeinsam getrage-

nes Verständnis entsteht. In einem nächsten Schritt identiﬁziert das Team die notwendigen

Aufgaben/Aktivitäten, die es braucht, um die gewünschten Anforderungen umzusetzen.

Jede Aufgabe/Aktivität wird durch das Team geschätzt, oder die vorhandene Schätzung

wird validiert. Dabei können unterschiedliche Schätzvorgehen zur Anwendung kommen.

Häuﬁg werden mittels dem Planning Poker Story Points geschätzt (siehe Abschn. 2.4.6.2).

Das Team überprüft die geschätzten Aufwände mit der verfügbaren Teamkapazität. Das

Team entscheidet schließlich, welche Anforderungen (Einträge aus dem Product Backlog)

im nächsten Sprint umgesetzt werden. Dadurch gibt das Team auch ein Committment ab,

was im Sprint umgesetzt wird. Zum Abschluss der Sprint Planung bildet das Team den

Sprint Backlog. Der Scrum Master moderiert den Prozess und unterstützt den Product

Owner und das Team im Prozess und in der Entscheidungsﬁndung.

Am Ende eines Sprints liegt ein realisiertes Inkrement vor. Das Inkrement hat die

Eigenschaft eines lauffähigen Produktes, unabhängig davon, ob es als Release an den An-

wender ausgeliefert wird oder nicht. Das heißt am Ende des Sprints müssen die im Sprint

Backlog aufgenommenen Anforderungen umgesetzt, lauffähig und vorführbar sein. Da-

durch wird sichergestellt, dass mit jedem Sprint ein Mehrwert geschaffen wird. In den

2.5

Phase Realisierung

199

Abb. 2.60 Praxisbeispiel BLS: Sprint Backlogs

ersten Sprints eines neuen Projektes können auch Konzepte, Architekturen oder funk-

tionierende Arbeitsumgebungen als Inkremente geschaffen werden. Spätestens ab dem

dritten oder vierten Sprint sollen jedoch funktionierende Teilergebnisse des zu realisie-

renden Produktes geschaffen werden.

Die Sprint Planung dauert 1–2 h und ﬁndet 1–3 Tage vor dem Start des Sprints statt.

Der Sprint Backlog (siehe Abb. 2.60) ist die Liste der Anforderungen, welche im

Verlaufe des nächsten Sprints umgesetzt wird. Er stellt das konkrete und überprüfbare

Ergebnis dar und dient zur Erreichung des deﬁnierten Sprint Ziels.

Der Sprint Backlog kann in einem Tool geführt werden. Am besten eignen sich dazu

Karten an einer Stellwand, am sogenannten Kanban Board. Dazu wird für jede Aufgabe

eine Karte erstellt. Das Kanban Board enthält beispielsweise folgende fünf Bereiche:

Aufgabe (To do)

In Bearbeitung (In Progress)

Entwickelt (Developed)

Prüfung (Review)

Erledigt (Done)

200

Methodik

Das Kanban Board kann durch weitere Bereiche ergänzt werden: Ideen, Backlog, Spe-

ziﬁkation, Integration, Auslieferung usw. Dadurch wird Transparenz geschaffen, der Fluss

der Arbeit wird als Prozess visualisiert. Das steigert beim Team das Verantwortungsbe-

wusstsein. Abb. 2.61 zeigt ein Kanban Board, welches in einem Tool geführt wird.

2.5.3

Sprintdurchführung/Daily Standup Meeting

Ist der Sprint geplant und sind die Sprint Backlogs erstellt, beginnt der Sprint. Die Länge

des Sprints wurde während der Release-Planung mit einer ﬁxierten Zeitdauer festgelegt.

Während des Sprints setzt das Team die im Sprint Backlog deﬁnierten Anforderungen

um. Ergeben sich während des Sprints neue Wünsche oder Änderungen, so werden diese

im Product Backlog aufgenommen. Der Sprint Backlog wird während der Sprintdurch-

führung weder verändert noch angepasst. Dadurch wird sichergestellt, dass das Team

während einer ﬁxen Dauer an deﬁnierten Themen arbeitet. Dies steigert die Efﬁzienz, und

das Team wird nicht durch neue Bedürfnisse oder Änderungen abgelenkt.

Die Verantwortung für die Durchführung des Sprints liegt beim Team. Das Team ar-

beitet selbstorganisiert und hält sich an die deﬁnierten Vereinbarungen der agilen Vorge-

hensweise.

Täglich ﬁndet das Daily Standup Meeting statt. An diesem Meeting nehmen der Pro-

duct Owner, das Team und bei Bedarf der Scrum Master teil. Dieses Meeting ist keine

Sitzung, in der man sitzt, sondern ein Stehmeeting, am besten direkt beim Kanban Board

mit dem Sprint Backlog. Das Daily Standup Meeting soll von kurzer Dauer (max. 15 min)

sein. Dabei werden durch jeden Teilnehmer folgende drei Fragen beantwortet:

Was habe ich seit dem letzten Daily Standup Meeting erledigt und erreicht?

Was werde ich bis zum nächsten Daily Standup Meeting erledigen?

Auf welche Probleme oder Unklarheiten bin ich gestoßen?

Der Sprint Backlog am Kanban Board kann gleich während des Standup Meetings

aktualisiert werden.

Am Daily Standup Meeting sollen keine Probleme ausdiskutiert oder Lösungen ge-

funden werden. Es ist ein reines Status- und Planungsmeeting. Dabei wird eine hohe

Transparenz erreicht. Es ist für jeden Teilnehmer klar, wer an was arbeitet und wer was er-

reicht hat. Diese Transparenz motiviert auch jedes einzelne Teammitglied, jeden Tag einen

Schritt weiter zu kommen und etwas zu realisieren. Dadurch wird auch ein klarer Fokus

auf das Sprint-Ziel gelegt. Probleme sollen im kleinen Kreis gelöst werden. Der Product

Owner steht als Fachvertreter für die Beantwortung von Fragen des Entwicklungsteams

zur Verfügung.

Weiter sollte am Daily Standup Meeting auch der Sprint-Fortschritt mittels eines Sprint

Burndown Charts überprüft werden. Der Sprint Burndown Bericht betrachtet, wie sich

die Aufwände im Sprint Backlog von Tag zu Tag entwickeln, wie Abb. 2.62 zeigt.

2.5

Phase Realisierung

201

Abb. 2.61 Praxisbeispiel BLS: Scrum Board (Kanban Board)

202

Methodik

Abb. 2.62 Praxisbeispiel BLS: Sprint Burndown Charts

2.5

Phase Realisierung

203

Die y-Achse zeigt die kumulative Anzahl der im Spring Backlog enthaltenen Aufwän-

de. Die x-Achse stellt die Anzahl Arbeitstage dar. Der ideale Burndown (linearer Strich

von links oben nach rechts unten) zeigt, welche Aufwände von Tag zu Tag erbracht wer-

den müssen, um das Sprint-Ziel zu erreichen. Der reale Burndown wird am Anfang der

idealen Linie hinterherhinken, sollte sich jedoch im Verlaufe des Sprints der idealen Linie

annähern.

Der Product Backlog ist eine dynamische Liste, welche laufend den neuesten Erkennt-

nissen und Bedürfnissen angepasst wird. Werden Details zu Einträgen hinzugefügt, Schät-

zungen erstellt, oder die Reihenfolge der Einträge im Product Backlog bestimmt, wird das

als Verfeinerung des Product Backlogs – oft auch als Reﬁnement oder Grooming – be-

zeichnet. Die Verfeinerung ist ein kontinuierlicher Prozess, an dem der Product Owner

und das Entwicklungsteam gemeinsam die Product Backlog-Einträge detaillieren. Bei der

Verfeinerung des Product Backlogs werden die Einträge begutachtet und revidiert. Das

Scrum Team bestimmt, wann und wie diese Verfeinerungsarbeit erfolgt. Der Product Ow-

ner kann jedoch jederzeit die Einträge im Product Backlog aktualisieren oder aktualisieren

lassen.

2.5.4

Sprint Review

Am Schluss eines Sprints ﬁndet das Sprint Review statt. Am Sprint Review zeigt das

Team, was es im zurückliegenden Sprint realisiert hat. Das Team macht eine Vorführung

und Demonstration des realisierten Inkrements. Während des Sprint Reviews wird

zusammen mit dem Product Owner geklärt, inwiefern das Sprint-Ziel und die im Sprint

Backlog deﬁnierten Anforderungen erreicht wurden. Dem Product Owner obliegt es zu

entscheiden, ob eine Anforderung erfüllt ist oder nicht. Nur Anforderungen, welche zu

100 % umgesetzt wurden, gelten als erfüllt. Wurde eine Anforderung nur zu 80 oder 90 %

umgesetzt, so gilt sie als nicht erfüllt und wird als Restanz in die nächste Sprint Planung

mitgenommen. Bezüglich der Umsetzung einer Anforderung gilt das Prinzip „alles oder

nichts“.

Neben dem Team, dem Product Owner und dem Scrum Master können am Sprint Re-

view auch weitere Stakeholder wie Auftraggeber, Vertreter aus Marketing oder Kunden

teilnehmen.

Ein Sprint Review dauert eine bis zwei Stunden.

2.5.5

Retrospektive

Zwischen dem Sprint Review und der Planung des nächsten Sprints ﬁndet eine Retrospek-

tive statt. Das Ziel der Retrospektive ist es, dass der Product Owner, das Team und der

Scrum Master gemeinsam eine Rückschau (Reﬂexion) auf den letzten Sprint durchführen

und Verbesserungsvorschläge evaluieren. Bewährt hat sich dafür folgendes Vorgehen:

204

Methodik

Die Teilnehmer machen sich Gedanken zu folgenden Themen und schreiben für jeden

Beitrag ein Kärtchen oder Post-it:

– Was ist gut gelaufen?

– Was ist schlecht gelaufen?

– Was könnte verbessert werden?

Die Teilnehmer hängen ihre Beiträge an eine Pinnwand, gruppiert zu den drei Frage-

stellungen.

Alle Teilnehmer betrachten die Beiträge und lassen diese auf sich wirken.

Jeder Teilnehmer kann seine Beiträge kommentieren und ergänzen.

In der Gruppe wird die Diskussion zur Fragestellung „Was könnte verbessert werden?“

geführt. Verbesserungsmaßnahmen werden gemeinsam in der Gruppe festgelegt und

entschieden.

Die Retrospektive wird durch den Scrum Master moderiert und geführt. Er achtet auf

konstruktive und sachliche Beiträge. Beiträge, welche andere Gruppenmitglieder persön-

lich angreifen, sind zu vermeiden.

Durch das Sprint Review und die Retrospektive werden das kontinuierliche Lernen

und Verbessern fest im Prozess verankert. Durch die beiden Besprechungen wird Wis-

sen generiert, der kontinuierliche Verbesserungsprozess wird angeregt. In vielen Fällen

erfolgt dadurch auch eine stetige Steigerung der Entwicklungsgeschwindigkeit (Veloci-

ty). Dadurch können während der ﬁxen Sprintdauer von Sprint zu Sprint immer mehr

Anforderungen und Themen umgesetzt werden. Dieser Verbesserungsprozess wird in der

schlanken Produktentwicklung auch Kaizen genannt.

2.5.6

Projektcontrolling

Übersicht

Projektcontrolling ist in der klassischen Vorgehensweise als eigenständiger Begriff anzu-

sehen und beschreibt die Prozesse und Regeln, die innerhalb des Projektmanagements zur

Sicherung des Erreichens der Projektziele beitragen. Projektcontrolling im übergeordne-

ten Sinn ist ein Zyklus in drei Etappen, wie in Tab. 2.40 beschrieben.

Elementare Basis für ein erfolgreiches Projektcontrolling sind das korrekte Festle-

gen verbindlicher Ziele sowie eine belastbare Planung. Im Projektcontrolling im engeren

Sinne werden aus dem Abgleich zwischen Soll- und Ist-Zustand Korrekturmaßnahmen

abgeleitet. Diese können zu angepassten Plänen oder zu geänderten Zielen – einem neuen

Soll-Zustand – führen. Die Projektleitung läuft in Zyklen ab: Bei guter Ausführung ist

sie auf das Ziel ausgerichtet, ansonsten dreht sich das Projekt im Kreis, wie in Abb. 2.63

gezeigt.

2.5

Phase Realisierung

205

Tab. 2.40 Projektcontrolling im Kontext des gesamten Projektmanagements

Deﬁnitionsetappe

Korrekte und vollständige Zielvereinbarung zwischen Auftraggeber und

Projektteam

Planungsetappe

Aus den Zielen lässt sich die Projektplanung ableiten und erarbeiten:

– Phasenplan

– Projektstrukturplan

– Termin-/Zeitplan

– Ressourcenplan

– Kostenplan

Steuerungsetappe

Im Rahmen des Projektcontrollings im engeren Sinne wird der Soll-Zustand

mit dem Ist-Zustand verglichen. Bei Abweichungen werden Korrekturmaß-

nahmen deﬁniert.

Störungen in Form von Konﬂikten oder Änderungsanträgen ﬂießen in dieser

Etappe ein und führen zu einem neuen Zyklusdurchlauf:

– Bewilligte Änderungen verändern die ursprünglichen Ziele in der Deﬁniti-

onsetappe

– Die Bearbeitung von Konﬂikten sowie Änderungen von Zielen führen zu

einer Anpassung der Planung in der Planungsetappe

Planung

• Phasenplan

• Projektstrukturplan

• Terminplan

• Ressourcenplan

• Kostenplan

Steuerung

• Inhalt, Qualität

• Termine

• Kosten, Ressourcen

• Konﬂikte

• Änderungen

Deﬁnition

• Ziele festlegen

Abb. 2.63 Projektcontrolling als Zyklus in drei Phasen

206

Methodik

Tab. 2.41 Aspekte des Projektcontrollings

Projektkontrolle

Kontinuierliche Überprüfung der Zielerreichung des Projektes bezüglich

Termine, Kosten und Qualität

Berichtswesen

(Reporting)

Das Berichtswesen umfasst Dokumentation und Kommunikation der

erreichten Ergebnisse im Projekt an die maßgeblichen Stellen und Ent-

scheidungsträger

Projektsteuerung

Aufgrund der Ergebnisse der Projektkontrolle werden Korrekturmaßnah-

men formuliert

Projektänderungen

(Abschn. 2.5.8)

Änderungen im laufenden Projekt werden dokumentiert: Anforderungen,

Technologie, Markt usw., Maßnahmen formuliert und umgesetzt

Projektbeurteilung

In regelmäßigen Abständen, mindestens aber am Ende jeder Projektpha-

se, wird das Projekt bezüglich vordeﬁnierter Kriterien und erwarteter

Risiken neu beurteilt

Projektcontrolling ist somit eine unmittelbare Führungsaufgabe der Projektleitung

in Zusammenarbeit mit Auftraggeber, Projektausschuss, Entscheidungsträger oder Ge-

schäftsleitung. Je nach Flughöhe wird zwischen den folgenden Begriffen unterschieden:

Strategisches Controlling (durch die Geschäftsleitung)

Multiprojekt-Controlling (durch das Projektportfolioboard oder den Projektausschuss)

(Einzel)projekt-Controlling durch die Projektleitung und den Projektausschuss

Die Tab. 2.41 fasst die Hauptaufgaben eines effektiven Projektcontrollings zusammen.

2.5.6.1

Projektkontrolle

Basis für diese Aufgabe bildet der aktuelle Projektplan. In regelmäßigen Abständen ist das

Projekt auf seine Termin- und Kostentreue zu überprüfen. Je komplexer oder zeitkritischer

das Projekt ist, desto kürzer müssen die Kontrollintervalle gesetzt werden.

Wenn viele Projektleiter mit großem Aufwand akribische Pläne erstellen, sollen sie

auch über geeignete Methoden verfügen, den Projektfortschritt gegenüber den Plänen zu

erfassen und zielführend zu steuern. Drei Aspekte ermöglichen dies:

Der Projektfortschritt wird objektiv bestimmt

Die gewonnenen Daten werden richtig interpretiert

Der Vergleich mit dem Soll-Zustand setzt klare, messbare Ziele voraus

Je nach Größe und Komplexität des Projekts können verschiedene Methoden zur Er-

fassung und Visualisierung des Projektfortschritts und zum Plan/Ist-Vergleich angewendet

werden. Genannt seien die Balkenplan- oder Arbeitspaket-Terminkontrolle, die Earned-

Value-Analyse und die Meilenstein-Trendanalyse.

2.5

Phase Realisierung

207

Stichtag

AC – Actual Cost

Ist-Kosten

PV – Planned Value

geplante Kosten

EV – Earned Value

Fertigstellungswert

Projektstart

Projektende

Mehraufwand

Zeitverzug

Kosten

Zeit

Abb. 2.64 Earned-Value-Analyse

Earned-Value-Analyse

Die Earned-Value-Analyse (auch als Leistungswertanalyse oder Fertigstellungswertme-

thode bezeichnet) dient zur Fortschrittsbewertung von Projekten. Sie lässt die drei Ele-

mente des „magischen Dreiecks“ Scope, Kosten und Zeit gleichzeitig in die Projektbeur-

teilung einﬂießen. Dies geschieht über die Berechnung der folgenden Größen:

Geplanter Aufwand (Planned value)

Fertigstellungswert (Earned value)

Ist-Aufwand (Budget burned)

Der Fertigstellungswert (Earned value) ist die zentrale Kennzahl in diesem Modell zur

Kontrolle des Projektfortschritts und den damit verbundenen Kosten (Abb. 2.64). Zum

Fertigstellungswert tragen nur Arbeitsaspekte bei, die vollständig abgeschlossen sind und

geprüft wurden (0 %/100 %)

Meilenstein-Trendanalyse

Die Meilenstein-Trendanalyse (MTA) zeigt auf, welche zeitliche Entwicklung sich im

Projekt abzeichnet. Voraussetzung dafür ist die Deﬁnition einer ausreichenden Zahl von

208

Methodik

Konzept

Realisierung

Einführung

Initialisierung

Beauftragung

Mar

Feb

Jan

Dez

Nov

Okt

Sep

Aug

Feb

Jan

Mar

Apr

Mai

Jun

Jul

Meilenstein-Termine

Berichtszeitpunkt

Einführung

Realisation

Konzept

Initialisierung

Beauftragung

Abb. 2.65 Meilenstein-Trendanalyse

Meilenstein-Terminen für das zu beurteilende Projekt. Diese Termine werden in regelmä-

ßigen Abständen auf ihre Erreichbarkeit überprüft und in ein Koordinatensystem übertra-

gen (Abb. 2.65).

Daraus ergibt sich für jeden Meilenstein eine Prognosekurve, die idealerweise hori-

zontal verläuft (keine Abweichung). Der erfahrene Projektleiter kann aus dem Verlauf

der Kurven eine Prognose für den zukünftigen Verlauf erstellen. Ihren besonderen Wert

erhält die Meilenstein-Trendanalyse aus der Kombination von Rückblick auf erreichte Er-

gebnisse und Ausblick auf noch zu erbringende Leistungen sowie im Vergleich zwischen

verschiedenen Projekten.

2.5.6.2

Berichtswesen (Reporting)

Die Berichterstattung an alle Anspruchsgruppen des Projektes gehört wahrscheinlich zu

den wichtigsten und gleichzeitig weniger beliebten Aufgaben des Projektleiters. Ein re-

gelmäßiger Austausch der Zwischenergebnisse mit den verantwortlichen Stellen und Ent-

scheidungsträgern stellt sicher, dass das Projekt auf Managementebene bekannt bleibt und

der Projektleiter im Problemfall rasch auf die entsprechende Unterstützung zählen kann.

2.5

Phase Realisierung

209

In einem Statusbericht, auch Fortschrittsbericht genannt, zuhanden der Entscheidungs-

träger (Kunde, Auftraggeber oder Projektausschuss) sollen in regelmäßigen Abständen

(häuﬁg im Monats- oder gar Wochenrhythmus) folgende Aussagen gemacht werden:

Welche Arbeiten bzw. Arbeitspakete wurden gestartet bzw. abgeschlossen?

Plan/Ist-Vergleich bezüglich Zeit, Kosten und Ressourcen

Können die noch verbleibenden Meilensteine mit allen Ergebnissen wie geplant er-

reicht werden?

Welche Probleme sind seit dem letzten Statusbericht aufgetaucht?

Welche Maßnahmen wurden getroffen? Wer löst bis wann das Problem?

Welche Risiken wurden in der Zwischenzeit neu identiﬁziert?

Wo ist Managementunterstützung notwendig?

Die kürzeste Variante beantwortet die Fragen:

Highlights: Was läuft gut?

Issues: Was läuft nicht nach Plan?

Es empﬁehlt sich, für jeden Issue einen Lösungsvorschlag auszuarbeiten, welcher vom

Entscheidungsträger idealerweise unterstützt und umgesetzt oder beauftragt werden kann.

Dadurch erhält der Projektleiter einen großen Einﬂuss und kann sein Projekt stark über

seine formellen Kompetenzen hinaus beeinﬂussen.

Das Berichtswesen dient als Basis für alle im Laufe des Projektes notwendigen

Steuerungs- und Kontrollmaßnahmen.

Vielfach wird das Berichtswesen in den Projektmanagement-Richtlinien geregelt. Da-

zu werden entsprechende Formulare bzw. Vorlagen zur Verfügung gestellt. Ampelsysteme

bewähren sich in der Praxis. Ein gemeinsames Verständnis aller Beteiligten über die Be-

deutung der einzelnen Ampelstufen ist sicherzustellen. Beispielsweise:

Grün: auf Kurs

Gelb: Eskalation an Projektleitung erforderlich. Projektleiter kann Maßnahmen ent-

scheiden und umsetzen

Rot: Eskalation an die Geschäftsleitung nötig. Die Geschäftsleitung muss über Maß-

nahmen entscheiden und diese umsetzen oder delegieren

Wenn verschiedene Beteiligte die Ampelstufen unterschiedlich deﬁnieren, sind Miss-

verständnisse und Leerläufe unvermeidlich.

Bei Metrohm ist der monatliche Statusbericht unter anderem mit folgenden Elementen

aufgebaut:

Projektstatus mit Ampeln, siehe Abb. 2.66

Meilensteine, siehe Abb. 2.67

210

Methodik

Projektkosten, siehe Abb. 2.68

Produktionskosten, siehe Abb. 2.69

Risikomanagement, siehe Abb. 2.70 und 2.71

2.5.6.3

Projektsteuerung

Ein Projekt muss situativ und ﬂexibel geführt werden können. Projekte und die dabei

auftauchenden Probleme sind so unterschiedlich und vielschichtig, dass es keine allge-

meingültige Formel für die Projektsteuerung gibt. Aufgrund der Ergebnisse der Projekt-

kontrolle müssen Maßnahmen für die steuernde Einﬂussnahme auf den Projektverlauf

deﬁniert werden.

Die Aufgaben des Projektleiters sind:

vereinbarte Projektkennzahlen aktualisieren und überwachen

Projektplan zur Erreichung des ursprünglichen Projektziels aktualisieren

Alternativ-Szenarien bei Abweichungen vom Projektplan erarbeiten

bei Bedarf zusätzliche Ressourcen und Finanzmittel anfordern

Aufgabenstellungen der Projektmitarbeiter verändern

Unteraufträge vergeben

mit dem Auftraggeber verhandeln

Beschlüsse des Projektausschusses umsetzen

Projektreviews und Projektaudits beantragen

Projektabbruch beantragen

Die Aufgaben des Auftraggebers/Projektausschusses sind:

zusätzliche Finanzmittel bewilligen oder ablehnen

zusätzliche Ressourcen (aus der Linie) bewilligen und durchsetzen

Freigabe für die nächste Projektphase erteilen

über den Abbruch von Projekten entscheiden

Projekt-Prioritäten ändern

Einige vorbeugende Maßnahmen für eine efﬁziente Projektsteuerung sind:

klar verständliche und messbar formulierte Ziele

situativ ﬂexible und rollende Projektplanung

periodische Koordinationssitzungen des Projektteams zur Klärung der aktuellen Si-

tuation, Eruierung künftiger Schwierigkeiten, Vereinbarung vorbeugender Maßnahmen

und zum Fällen von Entscheidungen

konsequentes Fällen von verbindlichen Entscheiden durch den Auftraggeber

periodische Teamsitzungen

Kontext- bzw. Umfeldanalyse

Reviews und Meilensteinsitzungen

2.5

Phase Realisierung

211

PROJECT STATUS REPORT

Project Type

EWP 100

23.09.2013

EWP Number

Reporting Date

KPIs:

Next MS

Go Live

Production Cost

Project Budget

Resources

Scope Deviations

Risk

07. Okt 14

03. Jul 16

Release Prototype

Market Release

OMNIS Project

Management Summary

Project on Track for Market Release, but delay of Prototype Release of 10 days due to late arrival of critical component
First titration-tests showed very good results, the ambitious requirements could be achieved
Major Decision: New Sample handling Concept will be implemented, as agreed with Product Management
Request: Investment 100k for automated production prozess is required, see separate evaluation and busienss case

Abb. 2.66 Praxisbeispiel Metrohm: Projektstatus mit Ampeln – Monatsreport Projekt OMNIS Titriersystem

212

Methodik

Milestone

Actual Plan

Last Approved

Dates

Initial Plan

(LH-based)

Status

01. Jan 12

19. Jul 12

04. Feb 13

23. Aug 13

04. Jul 13

next MS

07. Okt 14

27. Sep 14

08. Aug 14

19. Feb 16

09. Feb 16

21. Dez 15

20. Mär 16

30. Jan 16

19. Mai 16

30. Mär 16

Go Live

03. Jul 16

14. Mai 16

Start of project

Review Design Goals charter

Review URS

Review Design Input

Release Prototype

Review Design Transfer

System Freeze

System Release

Market Release

Abb. 2.67 Praxisbeispiel Metrohm: Meilensteine – Monatsreport Projekt OMNIS Titriersystem

2.5

Phase Realisierung

213

Project Costs (TCHF)

Abb. 2.68 Praxisbeispiel Metrohm: Projektkosten – Monatsreport Projekt OMNIS Titriersystem

214

Methodik

Production Costs (in CHF)

Dosierer

Venle

Target

Actual

Expected

Abb. 2.69 Praxisbeispiel Metrohm: Produktionskosten – Monatsreport Projekt OMNIS Titriersys-

tem

Probability

)tie

cilnie

niE(

Potenal damage

(Tragweite, Auswirkungen des Fehlers)

R3 (E:?)

R1 (E:3)

R4 (E:5)

R2 (E:2)

Abb. 2.70 Praxisbeispiel Metrohm: Risikomanagement – Monatsreport Projekt OMNIS Titriersys-

tem

2.5

Phase Realisierung

215

Top 5 Risks

Description

Level before

Level After

Status

(WxT)

R1: Präzision des Dosierers

erfüllt geforderte

Messgenauigkeit nicht

in Arbeit

R2:Neue Ventiltechnologie

funktioniert nicht

in Arbeit

R3: ASIC steht nicht

funktionsfähig zeitgerecht zur

Verfügung

in Arbeit

R4: UL-Zertifizierung wird

nicht erreicht

keine Aktivitäten notwendig

R5: Software steht nicht

ausreichend funktinosfähig

zur Verfügung

in Arbeit

Abb. 2.71 Praxisbeispiel Metrohm: Risikomanagement – Monatsreport Projekt OMNIS Titriersys-

tem

2.5.6.4

Projektbeurteilung

Im Normalfall werden die wichtigsten Teilschritte (Meilensteine) eines Projektes bereits

im Projektauftrag vereinbart. Meilensteine sind besonders geeignet für eine Projektbe-

urteilung, weil zu diesem Zeitpunkt klar abgegrenzte Lieferobjekte und Arbeitspakete

vollständig erfüllt sein müssen.

Meilensteinsitzungen ermöglichen eine kritische Standortbestimmung (Review) über

das bereits Geleistete und das noch Bevorstehende und den Reifegrad der vorliegenden

Zwischenresultate. Zusammen mit dem Auftraggeber bzw. dem Projektausschuss hat die

Projektleitung die folgenden Fragen verbindlich zu klären:

Ist die Erreichung der Projektziele nach wie vor gewährleistet?

Ist die Wirtschaftlichkeit des Vorhabens nach wie vor sichergestellt?

Welche Risiken können das Projekt gefährden?

Gelten die Annahmen noch oder sind neue Rahmenbedingungen aufgetaucht?

Gibt es offene Probleme, die eine Weiterbearbeitung des Projektes verhindern?

Wird die nächste Projektphase freigegeben? Mit welchen Auﬂagen?

Soll das Projekt vorzeitig abgebrochen werden?

Am Ende der Sitzung soll ein Protokoll mit allfälligen Auﬂagen, Verantwortlichkeiten

und Terminen erstellt und gegenseitig unterzeichnet werden.

216

Methodik

Nutzung, Betrieb

Projekt

Meilenstein

Review

Phase 3

Phase 4

Phase 2

Phase 1

Ebene 1

Ebene 2

Ebene 3

Meilenstein

Review

Nach-

kontrolle

Schluss

Review

Gate

Review

Abb. 2.72 Verschiedene Projekt-Reviews

Reviews und Audit zur Projektbeurteilung

Reviews sind kritische Überprüfungen während und nach Abschluss des Projektes, ob die

geforderten Ziele vollständig und in der geforderten Qualität erreicht wurden. Häuﬁg un-

terscheiden Organisationen verschiedene Ebenen von Reviews, wie in Abb. 2.72 gezeigt:

Meilenstein-Review bei jedem Meilenstein

Gate Review nach ausgewählten Meilensteinen mit besonders großer Tragweite

Schluss-Review inkl. Debrieﬁng und Lessons Learned bei Abschluss des Projekts

Nachkontrolle inkl. Nachkalkulation zur Überprüfung, ob Ziele ihre erwünschte Wir-

kung effektiv entfaltet haben.

Im Gegensatz zu einem Review überprüft ein Audit nicht die erreichten Resultate, son-

dern die Einhaltung geltender (externer oder selbst auferlegter) Vorgehensweisen.

Audit: prüft die Prozesskonformität

Review: prüft die Zielerreichung

Selbstverständlich kann im Rahmen eines Reviews auch die situationsbezogene Eig-

nung eines gewählten Ansatzes, einer Methodik oder von Tools überprüft werden. Es wird

2.5

Phase Realisierung

217

Tab. 2.42 Ziel und Beteiligte eines Projekt-Reviews

Hauptsächliches Ziel

Mögliche Beteiligte

Meilenstein-Review;

Gate Review;

Stage Gate Review,

Quality Gate Review

Steuerung des Projektprozesses

Beurteilung der

– Phasenziele, Termine, Finanzen

– Ressourcen

– Vorgehensmethodik

– Projektorganisation

– Information

– Kommunikation und Zusammenarbeit

– Ableiten von Konsequenzen für das wei-

tere

Vorgehen der folgenden Phase

– Projektleiter

– Projektteam

– Projektausschuss Kunden

– evtl. weitere Anspruchs-

gruppen

End Review

– Beurteilung der Projektzielerreichung

– kritische Rückschau auf den Projekt-

prozess

– Ableiten von Lessons learned, d. h. von

Maßnahmen für das betriebliche Projekt-

management

– Projektleiter

– Projektteam

– Projektausschuss interner

Auftraggeber

– externe Moderation

Nachkontrolle

– Beurteilen der langfristigen Zielerrei-

chung und Projekt-Auswirkungen

– Projektexternes Team

dann beurteilt, ob die entsprechende Methodik geeignet ist, die Ziele unter den gegebenen

Umständen zu erreichen. Tab. 2.42 zeigt die Ziele unterschiedlicher Reviews.

Häuﬁg wird die Möglichkeit von Reviews viel zu wenig zur (selbst)kritischen Rück-

schau genutzt, sei es für das laufende Phasencontrolling oder für die Auswertung des

ganzen Projekts. Ehrliche Reviews sind eine Chance, aufkeimende Probleme bereits zu

erkennen, wenn sie noch klein und lösbar sind.

In der agilen Vorgehensweise ﬁndet nach jedem durchgeführten Sprint (ca. alle vier

Wochen) ein Sprint Review statt. In der Teamretrospektive werden Verbesserungsmaß-

nahmen identiﬁziert. Dadurch entsteht eine lernende Organisation, die rasch auf Proble-

me oder geänderte Situationen reagieren kann. In der klassischen Vorgehensweise ist zu

prüfen, inwiefern solche Elemente aus der agilen Vorgehensweise übernommen werden

können.

2.5.6.5

Das 90 %-Syndrom

Schon relativ bald nachdem das Projekt so richtig in Gang gekommen ist, glauben ei-

nige Projektbeteiligte, dass bereits ein Großteil (90 %) der Projektarbeit erledigt ist, wie

Abb. 2.73 zeigt. Dieses Phänomen tritt auf, weil sich schon einige realisierbare Lösungs-

ideen abzeichnen, beispielsweise ein funktionierender Prototyp. Unterschätzt werden al-

lerdings die Hindernisse und noch nicht bekannten Probleme, welche dann in der Rea-

lisierungsphase auftauchen. Diese Aufwandschätzung wird typischerweise in der ersten

218

Methodik

Projektende

Geplant

Einschätzung

Effektiv

Fertigstellungsgrad

Zeit

100%

90%

Abb. 2.73 90 %-Syndrom

Hälfte des Projektes sehr optimistisch abgehandelt und erfordert meist eine Korrektur in

der zweiten Hälfte.

Um das 90 %-Syndrom zu vermeiden sind objektive Kontrollmethoden erforderlich.

Die sichersten Aussagen liefert die 0/100-Methode, die eine Tätigkeit erst nach vollständi-

ger Erledigung gelten lässt. Aufwändigere Verfahren erfordern die Deﬁnition einer Metrik

für die laufend erbrachten Ergebnisse in Relation zum geplanten Endergebnis (z. B. 50/50-

Methode).

2.5.7

Termin-, Kosten- und Ressourcenkontrolle

2.5.7.1

Termin- und Kostenkontrolle

Für die Termin- und Kostenkontrolle reicht üblicherweise eine Gegenüberstellung der

nachfolgenden Kennzahlen aus, wie in Abb. 2.74 dargestellt. Die dafür notwendigen,

aktuellen Daten müssen jedoch häuﬁg in aufwändiger Kleinarbeit zusammengetragen

werden (z. B. Auswertungen aus Rapportierungssystemen, Aussagen von Projektmitar-

beitern usw.). Dafür müssen die Plan- und Ist-Daten in kompatibler Form vorhanden sein:

2.5

Phase Realisierung

219

Terminplan

Dauer/Kosten

gemäss Initialplanung

abgeschlossen in %

Prognose

Berichtszeitpunkt

Kumulierte

Kostenkurve

Zeit

Soll

Ist

Kosten

Abb. 2.74 Projektstandbeurteilung und Kostenkontrolle

Geplante und effektive Dauer

Geplante und effektive Kosten

Erfüllungsgrad in %

Eine Projektstandesbeurteilung mit Kostenkontrolle sollte in einem vorab bestimmten

Rhythmus erfolgen. Die Intervalle sollen der gesamten Projektdauer angepasst werden

(wöchentlich, monatlich oder quartalweise). Es ist dabei nicht immer einfach abzuschät-

zen, ob die aufgelaufenen Kosten für die tatsächlich erbrachten Leistungen ausreichen.

Generell gelten folgende Voraussetzungen für eine wirksame Kostenkontrolle:

transparente Kostenplanung

rasche Verfügbarkeit des Kostenstandes

periodische Überprüfung der prognostizierten Endkosten

Erfolgen während des Projektes wesentliche Änderungen der Aufgabenstellung oder

liegen große Abweichungen zwischen den Plan- und Ist-Werten vor, ist die ursprüngliche

Planung zu überarbeiten. Für die verbleibenden oder noch nicht abgeschlossenen Tätig-

keiten wird die restliche Dauer (time-to-complete) und die zu erwartenden Restkosten

(cost-to-complete) ermittelt, wie Abb. 2.75 zeigt.

220

Methodik

Zeit

Soll 2

Soll 1

Ist

Kosten

Berichtszeitpunkt

Time-to-complete

Cost-to-complete

Abb. 2.75 Time-to-complete und Cost-to-complete

2.5.7.2

Ressourcenkontrolle

Der Personaleinsatz ist schwierig zu planen und noch schwieriger durchzusetzen. Stan-

den am Projektanfang keine Erfahrungswerte zur Verfügung oder wurden unrealistische

Aufwandschätzungen gemacht oder wurde von falschen Voraussetzungen und Annahmen

ausgegangen, können große Differenzen entstehen.

Erschwert wird in der Praxis das Problem dadurch, dass die geplanten Ressourcen oft

nicht zum vereinbarten Zeitpunkt oder im vereinbarten Zeitraum zur Verfügung stehen.

Mögliche Ursachen sind:

die Projektmanagementphilosophie hat sich im Unternehmen nicht etabliert

die Projektleitung wird vom Management nur halbherzig unterstützt

die Führungskräfte haben keinen Überblick über die von ihnen zugesagten Ressourcen

oder halten sich nicht an die vereinbarten Abmachungen

es wurden wesentlich mehr Projekte gestartet als Ressourcen für deren Bearbeitung

verfügbar sind

es gibt keine oder nur eine ungenügende Einsatzplanung und Koordination der verfüg-

baren Ressourcen

Projekte werden nicht zentral überwacht und priorisiert

2.5

Phase Realisierung

221

2.5.7.3

Kostentransparenz und realistische Beurteilung der wirtschaftlichen

Projektsituation

Damit notwendige Projektsteuerungsmaßnahmen zweckmäßig und angemessen sein kön-

nen, braucht es eine zuverlässige Beurteilung der Projektsituation. Neben dem Projekt-

fortschritt und dem Ressourceneinsatz muss die Kostensituation aktuell, vollständig und

realistisch beurteilt werden.

Bei der Planung und den Projektanträgen ist die Vollkostenrechnung anzuwenden,

d. h. sowohl die internen wie die externen Kosten sind zu berücksichtigen. Nicht nur

die direkten Projektkosten sind aufzuführen, sondern auch Folgekosten, die durch die-

ses Projekt ausgelöst werden: Betrieb, Folgeprojekte, Unterhalt, Außerbetriebsetzung. Als

Beurteilungskriterien sollten die Life-cycle-Kosten (Summe aus Projekt-/Einmalkosten

und Betriebskosten) verwendet werden, sofern der Auftraggeber dafür offen ist. Für eine

Optimierung wird die Break-Even-Analyse eingesetzt (siehe Abb. 2.54).

Bei Projektbeginn oder für ein Fixpreisangebot werden die Projektkosten nach bestem

Wissen und Gewissen geplant. Bedingt durch die Marktsituation oder aus Auslastungs-

gründen kann es sein, dass die Geschäftsleitung einen Auftrag zu einem nicht kostende-

ckenden Verkaufspreis unterschreibt. Das ist ein unternehmerischer Entscheid. Die Ver-

antwortung des Projektleiters wird trotzdem gemessen an den Werten der Planung. Jede

Planung beinhaltet Unsicherheit, z. B. verändern Einﬂüsse von außen das Resultat, oder

Managemententscheide werden verzögert. Der Projektleiter stellt diese Situation so realis-

tisch wie möglich dar, zeigt die Alternativen in Form von Szenarien auf, quantiﬁziert die

Planungsunsicherheit und zeigt die Konsequenzen, wenn ein Entscheid nicht wie geplant

getroffen wird.

Bei der Planung und der Kontrolle sind alle Kosten und Kostenarten zu erfassen und zu

unterscheiden: Arbeiten für verschiedene Lieferobjekte und Arbeitspakete, Investitionen,

externe Aufträge, Änderungsaufwand, Arbeiten unter Kulanz u. a. Um Erfahrungswerte

aufzubauen, wieviel geplant und wieviel tatsächlich gebraucht wurde, soll deﬁniert wer-

den, von welchen Kostenarten am Projektende Kennzahlen zu erstellen sind.

Es kann nicht detaillierter kontrolliert werden, als geplant wurde. Darum muss der Pro-

jektleiter schon bei der Planung überlegen, was er wie detailliert kontrollieren will. Bei

der Initialplanung entstehen „Planwerte“, bei der Projektkontrolle „Istwerte“. Die später

zu erfassenden Istwerte sind bei Projektbeginn im Finanzüberwachungssystem einzuge-

ben. Die Lieferobjekt- und Arbeitspaketstruktur beim Controlling muss übereinstimmen

mit derjenigen der Initialplanung. Wenn Änderungen zu großen Diskrepanzen geführt ha-

ben, sind diese Strukturen zu überarbeiten.

Für die Geschäftsleitung sind die von den Fachspezialisten abgeschätzten „Prognose-

werte“ aus jeweils aktueller Sicht der tatsächlichen Projektsituation wichtig. Wenn Ab-

weichungen von den erwarteten Werten bekannt werden, sollten die Verantwortlichen den

Auftraggeber bzw. die Geschäftsleitung rasch informieren. Dafür sind die Istwerte so rea-

listisch wie möglich zu erfassen. Ausgelöste Bestellungen sind ab dem Bestell-Zeitpunkt

zu erfassen. Die Folgekosten von getroffenen Entscheiden sind auch schon beim Entscheid

zu berücksichtigen. Änderungen im Projekt sind unvermeidbar. Der Projektleiter sollte

222

Methodik

dafür sorgen, dass Mehraufwand und Kosten durch Änderungen nachvollziehbar erfasst

werden. So hat er Argumente für den Auftraggeber oder bei Forderungen von Kunden und

Lieferanten (Nachforderungsmanagement/Claim Management Abschn. 2.5.8).

Wenn ein Projekt abgeschlossen ist, wird das Projektteam aufgelöst. Ob die Einspa-

rungsziele nach der Einführung tatsächlich erreicht werden, zeigt sich meist erst später.

Darum sollte ein Zeitpunkt festgelegt werden, an dem der Projektleiter zusätzlich zur

Resultatbeurteilung auch eine Nachkalkulation veranlasst und Ergebnisse mit dem Auf-

traggeber und den ehemaligen Teammitgliedern überprüft.

Wirtschaftlichkeit

Der Projektantrag ist die unmittelbare Entscheidungsbasis für die Bewilligung eines Pro-

jektes. Die zuständigen Entscheidungsträger lassen sich von den einfachen Fragen leiten:

„Was kostet das Vorhaben? Was bringt es?“ Diese Fragen müssen im Laufe des ganzen

Projektes regelmäßig überprüft werden. Fallen die Antworten nicht mehr eindeutig positiv

aus, ist über einen vorzeitigen Projektabbruch zu diskutieren und zu entscheiden.

Zur Berechnung der Wirtschaftlichkeit eines Vorhabens wird häuﬁg eine einfache

Kosten-/Nutzenanalyse durchgeführt. Bei komplexen Projekten werden klassische Ver-

fahren und Kennzahlen aus der Investitionsrechnung eingesetzt, z. B.:

Rentabilitätsrechnung

Return on Investment (ROI)

Kapitalwert-Methode

Break-even Analyse

Dynamische Payback-Methode

2.5.8

Projektänderungen, Change Request Management,

Claim Management

2.5.8.1

Projektänderungen

Projekte stehen in einem stark vernetzten und dynamischen Umfeld: Jederzeit können

Ereignisse eintreten, die auf das Projekt größere Auswirkungen haben.

Projekt-externe Ereignisse oder Einﬂussfaktoren wie rasche Veränderungen des Mark-

tes, neue Gesetze oder neue Mitbewerber sind jedoch schwierig zu kontrollieren. Sie treten

meist kurzfristig und überraschend auf.

Projekt-interne Ereignisse oder Einﬂussfaktoren sind teilweise voraussehbar, da das

Projekt unter eigener Kontrolle steht und somit die Entwicklungen verfolgt werden kön-

nen. Mit dem Fortschritt in der Realisierung entstehen projektintern aber auch neue Er-

kenntnisse, welche zu Änderungen führen können.

Grundsätzlich wird mit Projektänderungen in der agilen Vorgehensweise anders umge-

gangen als in der klassischen. In der agilen Vorgehensweise werden Änderungen in den

Product Backlog aufgenommen und durch den Product Owner priorisiert. Hier sind die

2.5

Phase Realisierung

223

Tab. 2.43 Unterschiede Änderungsmanagement und Nachforderungsmanagement

Änderungsmanagement (Change Request)

Nachforderungsmanagement (Claim)

Die Änderung wurde erst beantragt

Die Änderung wurde bereits umgesetzt

Abwägen von Vorteilen und Konsequenzen

eines Änderungsantrags

Allokation entstandener Zusatz-Kosten: Wer

bezahlt?

Erlaubt die sachbezogene Diskussion

Führt eher zu Durchsetzungsansprüchen

Ist ein selbstverständlicher Prozess in einer

dynamischen Welt

Lässt sich bei sehr umfangreichen und komple-

xen Projekten nicht immer vermeiden

Dauer und das Budget ﬁx. Die Aufnahme von Änderungen erfolgt durch eine andere Prio-

risierung im Product Backlog. Das heißt, wenn ein neu aufgetauchtes Feature als wichtiger

eingestuft wird als bereits bekannte Features, verschiebt sich die Implementierung letzte-

rer auf später, oder auf die Implementierung wird verzichtet. Das Änderungsmanagement

aus der klassischen Vorgehensweise ﬁndet daher in der agilen Vorgehensweise keine An-

wendung. Die folgenden Ausführungen haben Gültigkeit für die klassische Vorgehenswei-

se: Jedes Ereignis mit Änderungscharakter ist vom Projektleiter hinsichtlich seiner Aus-

wirkungen auf das Projekt zu untersuchen, insbesondere Auswirkungen auf Leistungs-,

Termin- und Kostenziele sowie Risiken. Unterschieden wird dabei zwischen zukünftigen

(Änderungs- bzw. Change Request Management) und bereits eingetretenen Änderungen

(Claim Management), wie in Tab. 2.43 dargestellt.

Auswirkungen auf inhaltliche und organisatorische Änderungen sind einfacher zu lösen

als zwischenmenschliche Aspekte. Damit Projektleitung und Projektteammitglieder auch

mit diesen umgehen können, brauchen sie besondere Kenntnisse und Fähigkeiten.

2.5.8.2

Änderungsmanagement (Change Request Management)

Das Änderungsmanagement umfasst die Organisation, Verwaltung und Abwicklung von

Änderungsanforderungen an Projektziele und -prozesse während des Projektablaufs nach

klassischer Vorgehensweise. Es ist deutlich abzugrenzen gegenüber Organisationsverän-

derungen und dem systemischen Veränderungsmanagement.

Projektänderungen können entstehen durch:

Kundenwünsche, Kundenbeanstandungen

Entwicklungsfehler

Neue Erkenntnisse, welche im Verlauf des Projekts gewonnen wurden

nicht mehr lieferbare Komponenten oder Materialien

geänderte Vorschriften

allgemeine Produktverbesserungen

Verbesserungsmöglichkeiten der Wirtschaftlichkeit

Änderungen sollen abhängig von ihrer Wichtigkeit und Dringlichkeit gehandhabt, in

einer To-Do-Liste zusammengefasst und gemeinsam in Versionen bearbeitet und freige-

224

Methodik

geben werden: Ist die Änderung umsetzbar? Ist sie notwendig? Welches Risiko, welchen

Nutzen, welchen Aufwand bringt sie mit sich?

Die Folgekosten müssen für das Unternehmen verkraftbar sein. Deshalb müssen Än-

derungen auch unter wirtschaftlichen Gesichtspunkten beurteilt und entschieden werden.

Bei Kundenprojekten ist zu klären, ob die Änderung unter Kulanz erfolgt oder als zusätz-

liche Forderung behandelt werden muss.

In vielen Unternehmen mit hohem Entwicklungsanteil ist der Change Request Ma-

nagement Prozess zwingend vorgeschrieben. Change Requests beantragt der Projektleiter

beim Gremium, das sämtliche größeren Änderungsbegehren freigibt. Ist kein Änderungs-

prozess installiert, sorgt der Projektleiter dafür, dass eine Entscheidungsinstanz und die

Verantwortlichkeiten deﬁniert sind. In diesem Expertenteam sollen die relevanten An-

spruchsgruppen vertreten sein. In der Praxis liegt es in der Kompetenz des Projektleiters

zu entscheiden, ob ein Änderungsantrag in Kulanz oder gegen zusätzliche Rechnung ab-

gewickelt wird.

Change Requests enthalten die folgenden Punkte:

Art der Änderung

Gründe für den Änderungsantrag

Von der Änderung betroffene Lieferobjekte und Arbeitspakete

Auswirkungen auf Projektkosten, Dauer und andere Projektteile

Auswirkungen einer Rückweisung des Änderungsantrags

Auswirkungen auf die Sicherheit, neu entstehende Risiken

Bezüge zu früheren Änderungsanträgen, welche sich jetzt auswirken

Für den Entscheid zuständige Instanz

Einwilligung des Kunden

Auftragserteilung (vom Design Change Request zum Design Change Order)

Abb. 2.76 zeigt eine Vorlage für einen Change Request Antrag.

Die Bearbeitung eines Änderungsantrags ist immer ein zweistuﬁger Prozess:

1) Änderungsantrag und Auswirkungsanalyse

Antragsteller schickt Änderungsantrag an Projektleiter

Projektleiter lässt den Antrag von allen potenziell betroffenen Projektmitarbeitern

oder Abteilungen prüfen auf

– Cost impact

– Timeline impact

– Risk impact

Die Summe der (zusätzlichen) Kosten, die Terminverschiebung und die zusätzli-

chen Risiken werden zusammengefasst

2.5

Phase Realisierung

225

Änderungsantrag Projekt Vertriebs-Back-End

15.05.2017

Vorlage Änderungsantrag

1 Idenﬁkaon Änderungsantrag

Ersteller/in:

Gesamtprojektleiter

Idenﬁkaons-Nr.:

(wird von der Projektleitung ausgefüllt)

005

Teilprojekt /

Arbeitspaket

Gesamtprojekt

Ansprechperson

Gesamtprojektleiter

Erstelldatum:

15.05.2017

Titel / Kurzbeschrieb:

Verkauf von Libero Abonnements

2 Einordnung des Antrages / Fehlermeldung

Kategorie:

(Zutreﬀendes bie

ankreuzen)

Terminverschiebung

Änderung / Erweiterung

Änderung der Verantwortlichkeiten / Organisaon

3 Aufwandschätzung

Teilbereich

Aufwand extern

Aufwand intern

Total

Mehrkosten für Realisie-

rung Verbund - Abonne-

ments

350‘000 CHF

160‘000 CHF

510‘000 CHF

Total

510‘000 CHF

4 Beschreibung des Problems

Der Verkauf von Libero Abonnements wurde in der Sormentserweiterung durch ZPS nach vorne gezogen. Bis

zum Fahrplanwechsel im Dezember 2017 muss der Verkauf von Libero Abonnements über den Webshop auf

bls.ch möglich sein. Zudem soll neu eine White-Label Shop-Lösung für andere Transportunternehmen zur Ver-

fügung gestellt werden. Sinnvollerweise wird diese Anforderung durch das Projekeam Vertriebs-Back-End um-

gesetzt.

Die Realisierung eines Webshops für den Verkauf von Libero Abonnements oder anderen Abonnements für den

öﬀentlichen Verkehr ist im Scope vom Projekt Vertriebs-Back-End nicht vorgesehen.

5 Gewünschte Änderung – mögliche Lösungsansätze

Geplanter Webshop soll in erster Priorität für den Verkauf von Abonnements umgesetzt werden. Der Verkauf

von Einzelckets für den öﬀentlichen Verkehr wird auf 2. Priorität zurückgestu.

6 Konsequenzen bei Nichtrealisierung

Die automasche Verlängerung von Abonnements der BLS Kunden werden ab Dezember 2017 über andere

Verkaufskanäle außerhalb der BLS abgewickelt.

7 Beilagen

Weitere Details sind in den Unterlagen des Steuerungsausschusses beschrieben.

Seite 1 von 2

Abb. 2.76 Vorlage „Änderungsantrag“

226

Methodik

Änderungsantrag Projekt Vertriebs-Back-End

15.05.2017

2 n

v 2 etie

alr

8 Genehmigung intern, Abteilung und Bereich

Instanzen (nur elektronisch, keine Unterschri nög)

Datum

Antragssteller

Gesamtprojektleiter

31.05.2017

9 Entscheid

Grund

Änderung wird realisiert

Sicherung des Verkaufs von Libero Abonne-

ments ab Dezember 2017

31.05.2017

Änderung wird nicht realisiert

Dokumentaon allfälliger Einschränkungen oder Bedingungen.

10 Unterschrien

Beauragende Instanz

Vorsitzender Steuerungsausschuss

________________________________________

______________________________________

________________________________________

Termin

Auragnehmende Instanz

Gesamtprojektleiter

Abb. 2.76 (Fortsetzung)

2.5

Phase Realisierung

227

2) Genehmigung und Umsetzung

Änderungsantrag (Scope Change) und Auswirkungsanalyse (Cost, Timeline, Risk)

werden dem Auftraggeber, Steuerungsausschuss bzw. Kunden zum Entscheid vor-

gelegt

Bei Annahme des Change Request werden das Projektbudget, die Termine und die

Risikoanalyse entsprechend angepasst. Das Projektteam wird ab jetzt an den neuen

Zielen gemessen.

2.5.8.3

Nachforderungsmanagement (Claim Management)

Wenn eine genehmigte Änderungsanforderung zusätzliche Kosten verursacht, das Pro-

jektergebnis geändert wird oder sich der Endtermin verschiebt, werden die benachteiligten

Projektpartner Nachforderungen (Claims) an die Verursacher stellen. Die Behandlung die-

ser Nachforderungen ist Bestandteil des Nachforderungsmanagements (Claim Manage-

ment), das an der Schnittstelle zwischen Änderungsmanagement und Vertragswesen posi-

tioniert ist.

Die systematische Überwachung und Beurteilung von Abweichungen bzw. Änderun-

gen sowie deren wirtschaftliche Folgen ist in komplexen Vorhaben ein wichtiger Faktor

für den Projekterfolg. Die Ermittlung von erbrachten Zusatzleistungen und den damit

verbundenen Ansprüchen dient als Basis für deren Abgeltung. Es ist die Aufgabe des Pro-

jektleiters, für angemessenen Ausgleich zwischen den Ansprüchen der Projektbeteiligten

und dem optimalen Projektablauf zu sorgen.

Um dies zu erreichen, sollten bereits im Vertrag die Gewährleistungsansprüche und

-fristen eindeutig geregelt und die Abnahme von Teilleistungen vereinbart werden. Im

Vertrag ist deshalb festzuhalten, welche Faktoren nicht beeinﬂusst und aus denen somit

keine Ansprüche geltend gemacht werden können. Das Thema Claim Management ist in

Projekten besonders heikel, da in der Startphase selten glasklar festgelegt werden kann,

was das Projekt zu leisten hat.

Es ist eine Kunst, im Projektvertrag die erwarteten Ergebnisse so eng zu fassen, dass

alles, was darüber hinausgeht, als Zusatzleistung gewertet und entschädigt wird. Ande-

rerseits soll der Leistungsbezieher mit dem Vertrag Minderleistungen beweisen können.

Das macht klar, dass die Dokumentation der Projektarbeit eine allfällige Beweisführung

ermöglicht. Unterstützt durch ein projektbegleitendes Qualitätsmanagement können so

Mängel rechtzeitig erkannt und ungerechtfertigte Nachforderungen eingeschränkt wer-

den.

Statt sich aber auf juristische Spitzﬁndigkeiten zu verlassen, ist im Sinne eines gu-

ten Images und langfristiger Zusammenarbeit ein partnerschaftliches Verhältnis zwischen

Projektauftraggeber und Auftragnehmer aufzubauen.

In der Praxis hilft hier das Führen einer „Plus-Minus-Liste“, welche Zusatz- und Min-

deraufwände aufzeigt und so eine gute Verhandlungsbasis für beide Parteien bietet. Die

Schritte des Clain Management sind in Abb. 2.77 dargestellt.

228

Methodik

Prävention

Lieferungs- und

Leistungsumfang

Vertragliche Ver-

einbarung über

Claim-Prozess

Vorbereitung

Verhandlungs-

ergebnisse zu

Lieferung und

Leistung in Ver-

trag einarbeiten

Verfahrensvor-

schrift im Projekt

umsetzen

Umsetzung

• Mögliche Claim-Ereignisse

erkennen

• Dokumentation

• Sachliche und kommerzielle

Prüfung

• Sachverhalt klären

• Claim-bedingte Forderungen

ausgleichen

Erfahrungs-

aufbau

• Checklisten

• Strategie

• Verfahrensvor-

schrift

Konzept

Realisierung

Einführung

Initialisierung

Beauftragung

Abb. 2.77 Schritte im Claim Management

2.5.9

Checkliste Abschluss Realisierungsphase

Agile und klassische Vorgehensweise:

Wie gut wurden alle im Projektauftrag vereinbarten Ziele erreicht?

Wie gut stimmen die erreichten Resultate mit den Vorgaben überein?

Ist die Einführung der Lösung beim Benutzer so geplant, dass sie auch realistisch

erfolgen kann?

Wie sind die begleitenden Maßnahmen wie Schulung, Anpassung der Organisa-

tion für die Einführung sichergestellt?

Wie groß ist die Akzeptanz für eine erfolgreiche Einführung? Reicht das aus?

Speziﬁsche Punkte der klassischen Vorgehensweise

Wurden Änderungen systematisch dokumentiert?

Welche Erfolge zeigen die geplanten Prüfungen und Tests am neuen Objekt: Pro-

dukt, System, Organisation?

2.6

Phase Einführung

229

Ist vor der ﬂächendeckenden Einführung ein Pilotversuch notwendig?

Welche Ergebnisse wurden nicht erreicht? Welches sind die Konsequenzen?

Zu welchen Mängeln gibt es keine Korrekturmaßnahmen?

Was ist bei der Überprüfung zum Abschluss speziell zu berücksichtigen? Welche

offenen Punkte bleiben bestehen?

Speziﬁsche Punkte der agilen Vorgehensweise

Wie funktionierten Selbstorganisation und Zusammenarbeit im Team?

Wurden die einzelnen Sprintziele erreicht?

Wie verlief die Lernkurve des Teams?

Hat sich die Entwicklungsgeschwindigkeit (velocity) im Verlaufe des Projektes

gesteigert?

2.6

Phase Einführung

Nach dem Abschluss der Realisierung wird das System in Betrieb genommen und einge-

führt. Bei einer Produktherstellung wird die Serienproduktion aufgenommen. Dienst-

leistungen werden aktiv angeboten oder die neue Organisation wird in Kraft gesetzt.

Jetzt beginnt die Phase der Nutzung. Hier werden Erfahrungen gesammelt, die für die

Verbesserung der vorliegenden Lösung und für die Gestaltung ähnlicher Systeme genutzt

werden können.

Wenn die neue Dienstleistung bzw. das neue Produkt beim Benutzer eingeführt ist,

muss die Projektorganisation wieder aufgelöst werden. Dazu gehört es, das Erreichte zu

würdigen und die Lehren aus dem Projekt zu ziehen. Dies gelingt am besten, wenn – nach

einer vereinbarten Zeit des produktiven Einsatzes der erarbeiteten Lösung – gemeinsam

mit Auftraggeber und Benutzer Bilanz gezogen wird.

2.6.1

Worauf kommt es in der Einführungsphase an?

Schritte dieser Phase

Tab. 2.44 zeigt die wichtigsten Schritte in der agilen und klassischen Vorgehensweise für

die Einführungsphase.

Ergebnisse der Einführungsphase

Eine gute Einführung der neuen Lösung und ein vollständiger Abschluss mit einer Aus-

wertung des Projektes sorgen dafür, dass das Projekt abgeschlossen werden kann und

230

Methodik

Tab. 2.44 Schritte Phase Einführung

Wichtigste Schritte

Für den Projektabschluss stehen die folgenden Arbeiten an:

– Benutzer befähigen, die neue Lösung produktiv zu nutzen

– Lösung einführen und in Betrieb setzen

– Kontrollieren, ob die Ziele erreicht sind

– Wartung und Unterhalt vorbereiten, Nachfolgeorganisation deﬁnie-

ren

– Schlussabrechnung und Nachkalkulation erstellen

– Bericht und Antrag zur Schlussbeurteilung erstellen

– Projektunterlagen an die Wartungsorganisation übergeben

– System an die Anwender oder dem Kunden übergeben (Abnahme-

Protokoll)

– Archivierung der Projektdokumentation vervollständigen und sicher-

stellen (besonders wichtig im Anlagebau bezüglich Produkthaftung)

– Das Projektteam bewusst auﬂösen

Für die Beurteilung der nachhaltigen Zielerreichung werden mit dem

Auftraggeber nach einer vereinbarten Nutzungszeit die Wirksamkeit und

der Ertrag der Projektziele nochmals überprüft. Evtl. ist eine sofortige

Überprüfung bei der Übergabe sinnvoller.

Worauf ist in der

Einführungsphase

besonders zu achten?

Das Projekt wirklich abschließen und in den Betrieb übergeben. Es ist

wichtig, dass nicht mehr die Projektmitarbeiter für den Betrieb zuständig

sind.

positive Eindrücke hinterlässt. Das Projektteam darf nicht dem „Fast-schon-fertig-Syn-

drom“ verfallen und sich innerlich vom Projekt verabschieden, bevor alle offenen Arbeiten

erledigt sind. Die Schlussfolgerungen aus allfälligen Fehlern können gezogen werden. An-

dere Projekte können vom erarbeiteten und dokumentierten Know-how proﬁtieren.

Wenn das Projekt fertig ist, kann folgendes festgestellt werden:

System, Produkt, Dienstleistung ist der Linie sorgfältig übergeben

Die Benutzer können damit produktiv umgehen

Das Abnahmeprotokoll ist unterschrieben

Die Nachkalkulation ist durchgeführt

Die Dokumentationen über Fachwissen und Erfahrungen liegen vor

Die Schlussbeurteilung ist durchgeführt

Das Projektteam ist entlastet und verabschiedet

Der Termin für die Nachkontrolle ist vereinbart

In der Einführungsphase sind Ergebnisse gemäß Tab. 2.45 relevant.

Mensch und Team

Mit der Einführung gehen sämtliche Aufgaben, Kompetenzen und Verantwortungen

(Abschn. 4.1.5) vom Projektteam über an die internen oder externen Abnehmer. Den gro-

ßen Erfahrungs- und Wissensvorsprung, den das Projektteam aufgebaut hat, gilt es nun an

2.6

Phase Einführung

231

Tab. 2.45 Ergebnisse der Einführungsphase

Agile Vorgehensweise

Klassische Vorgehensweise

Grundsatz

Bezüglich der Information stehen die Betreiber und Benutzer im Fokus. Die

Aktualisierung und Komplettierung der Dokumente ist für die Projektbetei-

ligten oft unattraktiv, da das Projektziel erreicht ist und mit Dokumenten für

die Nachwelt kaum mehr Lorbeeren geholt werden können. Mit der Einfüh-

rung kann die Brauchbarkeit der Dokumente geprüft werden. Spätestens bei

Revisionen werden die Unterlassungen sichtbar. Die Geschichte holt jetzt

die damaligen Projektverantwortlichen wieder ein!

Prozessorientierte

Ergebnisse

– Projektabschlussbericht: Ergebnisse, Aussagen zum Projektprozess,

administrative Abschlussarbeiten.

– Schlussabrechnung

– Abnahmeprotokoll

Inhaltsorientierte

Ergebnisse

– Schulungsunterlagen, aktualisierte

Instruktionen für Benutzer, Bedie-

nungsanleitungen

– Aktualisierte Ergebnisdokumente

– Product Backlog mit nicht reali-

sierten Features.

– Archivierung

– Schulungsunterlagen, aktualisierte

Instruktionen für Benutzer, Bedie-

nungsanleitungen

– Aktualisierte Ergebnisdokumen-

te, z. B. Baupläne, Dokumente der

Programmierung, Produktbeschrei-

bungen

– Archivierung

die operativ Verantwortlichen zu übergeben. Nur wenn das gelingt, wird es möglich sein,

die wirtschaftlichen Ziele des Projektes wirklich zu erreichen.

Folgende Maßnahmen und Kompetenzen sind wichtig:

In der Einführung wird das Projektteam intensiv mit den Werten und der Kultur des

internen oder externen Leistungsabnehmers konfrontiert (Abschn. 3.4). Die Erfolgs-

faktoren der Zusammenarbeit sind von hoher Relevanz.

Zum erfolgreichen Know-how-Transfer vom Projektteam zum Kunden oder internen

Abnehmer sind die drei Ebenen der Zusammenarbeit neu aufeinander abzustimmen

(Abschn. 1.5).

Für die „inhaltlichen“ Schulungen ist eine Beziehung zwischen dem Projektteam und

den Abnehmern aufzubauen, die Grundvoraussetzung für den gegenseitigen Respekt

und das Vertrauen ist (Abschn. 3.3.7). Adäquate organisatorische Maßnahmen sind zu

treffen.

Die Repräsentanten des Kundensystems verfügen über unterschiedliche Kompetenzen,

was zu Widerstand und Konﬂikten führen kann. Konﬂiktmanagement (Abschn. 4.4) ist

in dieser Phase relevant.

Möglicherweise werden schon während der letzten Projektphase einzelne Mitglieder

des Teams abgezogen. Die Projektverantwortlichen sollen in diesem Umbruch einen

guten Prozess des „Adjourning“ (Abschn. 4.2.5) gewährleisten.

232

Methodik

Da im Projekt unter Zeitdruck innovative Lösungen erzielt werden müssen, gelingt

nicht immer alles. Darum ist es wichtig, mit dem Scheitern gut umzugehen: „Diene ich

dem Scheitern?“ oder „Dient das Scheitern mir?“ (Abschn. 3.8.5).

Lernende Organisation: Das Projektreview oder die Retrospektive bieten die einmalige

Gelegenheit zu analysieren, was im Projekt gut gelaufen ist und wo Fehler entstanden

sind. Diese Analyse ist wieder auf den drei Ebenen der Zusammenarbeit zu machen

(Abschn. 1.5). Alle drei Ebenen basieren auf gut entwickelten Kompetenzen der Kom-

munikation (Abschn. 3.9).

Mit dem Projektabschluss sind die Leistungen aller Involvierten zu würdigen. Aner-

kennung ist ein wichtiges persönliches Grundbedürfnis (Abschn. 3.3.3) und stärkt die

zukünftige Motivation (Abschn. 3.7) für Projektarbeit.

2.6.2

Einführungsarten

Die Einführung ist rechtzeitig zu planen und vorzubereiten. Idealerweise wird für die Vor-

bereitung der Einführung ein Einführungskonzept in der Phase Konzept oder Realisierung

erarbeitet.

Eine neue Lösung kann auf drei Arten eingeführt werden:

Schlagartig auf einen deﬁnierten Termin (Big Bang Ansatz)

Stufenweise, Teilbereich nach Teilbereich

Parallel: Alte und neue Lösung werden gleichzeitig betrieben, bis die neue funktioniert

und bedient werden kann.

Oft ist es schwierig, im Vorfeld genau abzuschätzen, wie sich ein System, eine Anlage

oder eine Prozessanpassung im produktiven Einsatz bewährt. Trotz guter Vorbereitungen

und umfassenden Tests kann es zu unliebsamen Überraschungen kommen, z. B. Perfor-

manceschwierigkeiten bei einer Software. Daher ist eine stufenweise Einführung emp-

fehlenswert. Sollten Probleme auftauchen, so ist nur ein Teilbereich eines Unternehmens

betroffen. Aus der stufenweisen Einführung können die gewonnenen Erfahrungen auch

fortlaufend berücksichtigt werden. Ein paralleler Betrieb von zwei Lösungen ist kosten-

aufwändig und lässt sich selten über einen längeren Zeitraum aufrechterhalten. Der Big

Bang Ansatz sollte nur in Ausnahmefällen gewählt werden, da dieses Vorgehen hohe

Risiken beinhaltet. Er kann im Zuge der Lancierung eines neuen Produktes oder einem

neuen Service am Markt der Ansatz erster Wahl sein.

Zur Vorbereitung der Einführung sind folgende Punkte zu klären:

Art der Einführung, Einführungsvorgehen

Einführungsmaßnahmen

Einführungsorganisation

Einführungsplanung

Planung der Vorabnahmen und Abnahmen

2.6

Phase Einführung

233

Je nach Art des Projektes muss die Einführung minutiös geplant werden. In gewissen

Fällen macht es Sinn, einen detaillierten Ablaufplan der Einführung mit Checklisten zu

erstellen. Daraus sollte auch ersichtlich sein, wer was wann macht. Ein solcher Ablaufplan

sollte vor der produktiven Umsetzung bereits ein oder zweimal probeweise ausgeführt

werden. Bei der Einführungsplanung ist es zudem von großem Vorteil, eine Rückfallebene

oder einen Plan B vorzubereiten.

In der Vorbereitung wird überlegt, wie der Übergang vom Alten zum Neuen ge-

staltet werden kann. Dabei sind die Prinzipien des Organisation-Change-Management

(Abschn. 1.4.4) zu beachten.

2.6.3

Abnahme und Inbetriebnahme

2.6.3.1

Abnahme

In der vorangegangenen Phase wurde das Produkt oder die Dienstleistung realisiert und

getestet. Basierend auf den Tests in der Realisierungsphase oder auf speziellen Abnahme-

tests werden die Lieferobjekte durch den Auftraggeber abgenommen. Der Auftraggeber

kann diese Kompetenz auch delegieren, z. B. an den Product Owner in der agilen Vorge-

hensweise. Es hilft, wenn für die Abnahme klare Abnahmekriterien deﬁniert wurden. Die

Abnahmekriterien in der klassischen Vorgehensweise sollen sich an den Anforderungen

und dem Lösungskonzept orientieren.

2.6.3.2

Inbetriebnahme

Je nach Projektart erfolgen die Inbetriebnahme und effektive Nutzung der Anlage, des

Produktes oder der Software vor oder während der Abnahme. Bei Dienstleistungen oder

Organisationsanpassungen ist weniger von einer Inbetriebnahme die Rede. Da erfolgt im

Anschluss an die Abnahme die produktive Nutzung. Je nach Größe des Projektes ist es

sinnvoll, bereits in der Realisierungsphase Vor- und Teilabnahmen durchzuführen.

2.6.3.3

Produktivsetzung in der agilen Vorgehensweise

In Scrum wird aus mehreren Sprints ein Release gebildet. Ein Release ist eine auslie-

ferbare Produktversion, welche produktiv gesetzt und den Anwendern zur Nutzung zur

Verfügung gestellt wird. Der Release-Plan wird in der Phase Konzept erarbeitet.

2.6.3.4

Pilotversuch, Nullserie

Bei der Einführung neuer Arbeitsabläufe oder Infrastruktur in einem Unternehmen ist es

sinnvoll, über einen Pilotversuch oder eine Nullserie die Praxistauglichkeit in einer be-

grenzten Organisationseinheit zu überprüfen und erst danach eine Ausdehnung auf die

anderen Organisationseinheiten, Unternehmen der Gruppe oder weitere Länder durchzu-

führen.

Wenn ein Prototyp erfolgreich hergestellt werden konnte, heißt das noch nicht, dass

der Herstellungsprozess beherrscht wird. Durch die Herstellung einer Nullserie mit dem

234

Methodik

vorgesehenen Herstellungsprozess können die Prozesse optimiert und allfällige Fehler

rechtzeitig eliminiert werden.

2.6.3.5

Von der Nullserie zur Serienproduktion

Neues System in Betrieb nehmen

Einführung vorbereiten und überwachen

Konsolidierung, Mängel beheben

Organisatorische Regelungen treffen und einführen

Neues System den Benutzern übergeben, Serienproduktion starten

2.6.4

Benutzerschulung/Ausbildung

2.6.4.1

Konzeption Benutzerschulung

Das Ziel der Schulung ist, dass Benutzer mit dem neuen Produkt umgehen oder die neue

Dienstleistung erbringen können. Die Weiterentwicklung der Fähigkeiten der Mitarbeiter

ist ein Garant für die Überlebensfähigkeit des Unternehmens.

Wenn Erfahrungen aus der Pilotphase bzw. von der Nullserie vorhanden sind, können

diese für die benutzerorientierte Dokumentation (z. B. Bedienungsanweisung) und für die

Schulung der Benutzer eingesetzt werden. Welche Schulungsform am besten passt, ist von

verschiedenen Faktoren abhängig:

Gibt es verschiedene Zielgruppen?

Wer ist für die Schulung vorgesehen?

Welche Informationen aus dem Projekt müssen vermittelt werden?

Wie groß ist der Schulungsumfang?

Wann soll trainiert werden? Auf welche Art?

Müssen alle Benutzer gleichzeitig mit der neuen Lösung arbeiten?

Ist die Schulung kurz und heftig, oder ist eine sanfte Einführung vorteilhafter?

Wie werden spätere Benutzer nachgeschult?

2.6.4.2

Arten der Benutzerschulung

Bei jeder Art von Vermittlung neuen Wissens oder neuer Fähigkeiten muss die Frage

nach dem Ziel der Schulung gestellt werden: Was sollen die Teilnehmer nach dem Lehr-

gang wissen bzw. können? Je nach der Situation und Anforderungen eignen sich folgende

Möglichkeiten:

e-learning

Gebrauchsanleitung, Benutzer-Handbuch

Direkthilfe auf dem Bildschirm (Online Help)

Seminar, Workshop

train-the-trainer, power user

2.6

Phase Einführung

235

2.6.5

Überführung in die Betriebsorganisation

Neben der Einführung, Abnahme und Inbetriebnahme und der Benutzerschulung sind

auch die Betriebsorganisation vorzubereiten und die realisierten Ergebnisse an diese Be-

triebsorganisation zu übergeben.

2.6.5.1

Vorbereitung Betrieb

In einem ersten Schritt sind folgende Fragen zu klären:

Wie sieht die Betriebsorganisation aus? Wie ist diese Organisation in die Aufbauorga-

nisation integriert?

Wie sehen die Betriebsprozesse aus?

Welche Aufgaben gibt es im Betrieb zu erledigen?

– Support von Anwendern, Kunden usw. (Supportorganisation evtl. mehrstuﬁg)

– Überprüfung von Prozessschritten

– Periodische Abschlussarbeiten

– Überprüfung und Anpassung von Konﬁgurationseinstellungen

– Archivierung von Daten

– Benutzerverwaltung

Braucht es eine Betriebsinfrastruktur? Wenn ja, wie sieht diese aus?

Wie wird mit Störungen und Fehlern umgegangen?

Sind Wartungs- und Instandhaltungskonzept erstellt?

Ist die Wartung organisiert?

Sind die Garantieleistungen sichergestellt?

Sind je nach Projektart noch weitere Punkte zu berücksichtigen?

2.6.5.2

Betriebsorganisation

Wenn die Grundlagen für den Betrieb geregelt sind, ist die Betriebsorganisation aufzubau-

en und vorzubereiten.

Die Mitglieder der Betriebsorganisation sind auszubilden. Sie übernehmen idealerwei-

se aktiv Aufgaben bei den Einführungsmaßnahmen.

2.6.5.3

Betriebsübergabe

Die realisierten Ergebnisse und die Dokumentation werden dem Betrieb übergeben. Ne-

ben dem Anwendungs- und dem Betriebshandbuch gehören auch die Systemkonzepte,

Anforderungen und Lösungskonzepte zu der Dokumentation, welche in den Betrieb über-

geben werden. Die Betriebsorganisation hat zu klären, wie und ob diese Unterlagen weiter

genutzt werden. Es ist sinnvoll, den Product Backlog als Grundlage für die kontinuierli-

che Weiterentwicklung weiter zu nutzen. Die Dokumentation soll nicht erst am Schluss,

sondern während des Projektes konzipiert, eingerichtet und laufend gepﬂegt werden.

236

Methodik

Rückschau aus der Metaebene

Projektstart

Beziehungsebene

Inhaltliche Ebene

Organisatorische Ebene

Projektende

Abb. 2.78 Projektrückschau

2.6.6

Projektabschluss

Am Ende des Projektes erfolgt die Projektschlussbeurteilung. Diese Beurteilung dient

einerseits dazu, gewonnene Erfahrung weiterzugeben und die Grundlage für den Projekt-

abschluss zu liefern. Idealerweise beinhaltet die Projektrückschau die unterschiedlichen

Ebenen wie in Abb. 2.78 aufgezeigt.

Die Projektschlussbeurteilung auf der inhaltlichen Ebene gibt Auskunft zu folgenden

Themen:

Beurteilung der Zielerreichung

– Was wurde erreicht und was nicht?

– Welche Ergebnisse wurden geliefert?

Plan/Ist Vergleich zu Kosten und Terminen

Beurteilung der Wirtschaftlichkeit

Allfällige Folgekontrollen im Betrieb – auch nach Ablauf der Garantiefrist – zu Wirt-

schaftlichkeit usw.

2.6

Phase Einführung

237

Neben der inhaltlichen Auswertung, organisatorischen und administrativen Abschluss-

arbeiten soll auch die Zusammenarbeit bewusst reﬂektiert und abgeschlossen werden

(Abschn. 4.2.5):

Wie hat das Team gearbeitet? Wurden die persönlichen Ziele erreicht?

Was kann aus dieser Erfahrung gelernt werden?

Bestehen schlechte Gefühle oder nicht aufgearbeitete Probleme, die zur Sprache ge-

bracht und zu einem Abschluss geführt werden müssen?

Spätestens hier müssen sich der Projektleiter, der Product Owner und der Scrum Master

damit auseinandersetzen, wie die Zukunft der Projektteammitglieder aussieht: Wohin

gehen sie zurück? Ist ihr Platz in der „Herkunftsorganisation“ gesichert? Brauchen sie

eine Empfehlung oder aktive Unterstützung für ihr Weiterkommen?

Bei jedem Projekt und damit auch mit jeder Projektorganisation soll ein ofﬁzieller Ab-

schluss gemacht werden. Damit werden die Projektgremien entlastet und können sich

wieder neuen Aufgaben widmen. Das Projekt ist natürlich nie ganz zu Ende. Es gibt

Nach- bzw. Garantiearbeiten oder es sind Dokumentationen nachzutragen. Dies kann or-

ganisiert und durch beauftragte Einzelpersonen wahrgenommen werden.

Projektmitarbeit wird oft als wichtiges Element für die persönliche Weiterentwicklung

empfohlen. Doch gerade in Projektteams ist die Mitarbeiterförderung noch unterentwi-

ckelt. Die Zusammenarbeit hat mit einer speziellen Startveranstaltung begonnen. Nun soll

sie auch in einem angemessenen Rahmen beendet werden. Dies ist insbesondere dann von

Wichtigkeit, wenn das Projektresultat nicht nur positiv aussieht. Abschließende Klärung

schafft Freiraum für neue, verbesserte Zusammenarbeit.

Analog zum Kick-off soll auch eine Schlussveranstaltung durchgeführt werden. Der

Abschluss soll auf den gleichen drei Ebenen wie der Kick-off erfolgen: Der Prozess wird

auf den unterschiedlichen Ebenen auf sinnvolle Art und Weise beendet, die Erfolge sollen

gefeiert werden.

Organisatorische Themen für die Schlussveranstaltung:

Einführung und Schulung der künftigen Benutzer

Aufbau und Überprüfung der Nachfolgeorganisation: Wer betreibt die Lösung?

Kritische Rückschau: Wie zweckmäßig war die Projektorganisation?

Was kann das Unternehmen daraus für später lernen?

Würdigung der Teamleistungen, Entlastung der Projektmitglieder

Rückmeldungen der Leistungen der Teammitglieder an Führungskräfte

Bewusste Auﬂösung der Projektorganisation

Evtl. Hilfestellungen für die Reintegration der Teammitglieder in die Stammorganisa-

tion anbieten

Organisation der Nacharbeiten und der späteren Erfolgsüberprüfung (Nachkontrolle)

238

Methodik

2.6.7

Checkliste „Abschluss Einführungsphase“

Agile und klassische Vorgehensweise:

Ist es notwendig und vorgesehen, den im Projektauftrag formulierten Nutzen zu

überprüfen?

Wurden die erreichten Resultate mit den Anforderungen des Auftraggebers ver-

glichen?

Stimmt die Funktionalität des Produktes, der Dienstleistung?

Entspricht die Wirkung des Produkts/der Dienstleistung den Zielsetzungen?

Funktioniert die Organisation, welche den richtigen Umgang mit dem Pro-

dukt/der Dienstleistung sicherstellt?

Wurde der Abschlussbericht genehmigt?

Hatten die Mitglieder des Projektteams Gelegenheit, die Zusammenarbeit zu ana-

lysieren und sich gegenseitig Feedbacks zu geben?

Wurden in einem gemeinsamen Rückblick positive und negative Erfahrungen zu

Aufwand, methodischem Vorgehen und Zusammenarbeit ausgewertet und Maß-

nahmen eingeleitet, welche den Know-how-Transfer zu anderen Projekten und

die systematische Prozessverbesserung sicherstellen?

Wurde eine Liste mit allen offenen Punkten erstellt und deren Umsetzung ge-

plant? Ist allen Beteiligten klar, wer bis wann welche Abschlussarbeiten erledigt?

Wo haben die Projektteammitglieder nach Ende des Projektes wieder eine adä-

quate Beschäftigung?

Sind die Ansprechpartner für zukünftige Fragen oder Probleme deﬁniert und al-

len Nutznießern der Projektergebnisse bekannt?

Wer überprüft wann die Nachhaltigkeit und die Wirksamkeit des Projekts?

Wer rechnet wann nach, ob die in der Wirtschaftlichkeitsrechnung geplanten Er-

gebnisse erreicht werden, welchen ﬁnanziellen Nutzen das Projekt entfaltet und

wie gut das den Prognosen entspricht?

Speziﬁsche Punkte der klassischen Vorgehensweise

Sind alle Projektdokumente erstellt und abgeschlossen? Wurden alle notwendi-

gen Informationen an die künftigen Benutzer übergeben?

Wurde die Dokumentation auf Vollständigkeit überprüft und archiviert?

Wurde ein Abnahmeprotokoll erstellt und vom Auftraggeber/Kunden unter-

schrieben?

Hat der Projektleiter eine Beurteilung der Leistungen der Projektmitarbeiter

durchgeführt?

Wurden Spitzenleistungen identiﬁziert und angemessen anerkannt?

2.7

Projektportfolio- und Programmmanagement

239

Speziﬁsche Punkte der agilen Vorgehensweise

Wurde der Product Backlog mit den noch nicht realisierten Wünschen, Anforde-

rungen und Features an die Linie oder Produktmanagement übergeben?

2.7

Projektportfolio- und Programmmanagement

2.7.1

Projektportfolio und Multiprojektmanagement

Organisationen haben viel mehr Projektideen als Ressourcen, die Ideen umsetzen zu kön-

nen. Darum muss eine Projektidee in die formulierte Strategie passen und die gewünschten

Rahmenbedingungen erfüllen, bis sie Platz im strategischen Projektportfolio ﬁndet. Die

Unternehmensleitung muss dafür sorgen, dass die vorhandenen Ressourcen zielgerichtet

eingesetzt werden. Mit dem Portfolio soll verhindert werden, dass zu viele Projekte gleich-

zeitig in Angriff genommen werden und sich diese Projekte bei der Ressourcenzuteilung

zu stark gegenseitig behindern. Neben der Ressourcenfrage sind im Projektportfolioma-

nagement aber noch weitere Fragen zu beantworten, wie in Tab. 2.46 aufgelistet.

Um die Verknüpfung zwischen Unternehmensstrategie und Projektsteuerung (Priori-

sierung) herzustellen, ist eine möglichst vollständige Übersicht der „beabsichtigten“ und

„laufenden“ Vorhaben zu erarbeiten. Ein Projektportfolio ist eine Übersicht über alle

vorhandenen Projekte und Programme, welche in Form einer strukturierten Liste oder

graﬁsch nach unterschiedlichen Kriterien geordnet dargestellt werden.

Der Multiprojektmanagement-Prozess umfasst die Führung aller Projektmanagement-

Prozesse der Aufgaben-Konﬁguration und der Priorisierung und Kontrolle von Projekt-

portfolios.

Tab. 2.46 Zu beantwortende Fragen im Projektportfoliomanagement

Wie sieht der Portfoliomix

aus?

Welches sind die richtigen Projekte?

Wann ist der richtige Zeitpunkt, mit einem Projekt zu beginnen?

Welche Projekte laufen überhaupt? Welche laufen auch noch

nächstes Jahr?

Zu viele Projekte?

Sind alle Projekte sinnvoll und nötig? Birgt die Menge der Projek-

te Risiken?

Welche sind die wirklich wichtigen Projekte?

Auswirkungen von Projekt-

Verzögerungen?

Wird ein anderes Projekt davon betroffen?

Was bedeutet das für die Ressourcen (Finanzen, Personen)?

Zukünftig benötigte Qualiﬁ-

kationen?

Wer ist überhaupt in welchen Projekten eingesetzt?

Wie lange noch?

Welche Anforderungen haben geplante Projekte? Sind die Skills

vorhanden?

240

Methodik

In der Praxis werden die Begriffe Projektportfolio- und Multiprojektmanagement oft

für das Gleiche verwendet.

Der Projektleiter hat verschiedene Schnittpunkte mit dem Projektportfoliomanagement

zu berücksichtigen. Er hat vor allem Informationen zu seinem Projekt an das Projekt-

portfoliomanagement zu liefern. Dabei handelt es sich um Informationen zu Bewertung,

Abhängigkeiten, Ressourcen oder zum Projektfortschritt. Das Projektportfoliomanage-

ment macht gegenüber dem Projektleiter auch Vorgaben über die Form des Reportings

oder über die zur Verfügung stehenden Mittel.

2.7.1.1

Multiprojektmanagement: Problemfelder, Aufgabenfelder und

Elemente

Keine Transparenz und mangelnde Informationen zu den Projekten oder die Ad-hoc

Steuerung von Projekten sind zwei weit verbreitete Phänomene in Unternehmen. In der

Folge werden oft falsche Entscheide getroffen. Abb. 2.79 zeigt die Problemfelder des Mul-

tiprojektmanagements im Alltag. Aus diesen Problemfeldern lassen sich Aufgabenfelder

und Elemente für das Multiprojektmanagement ableiten (Kunz 2007, S. 24).

Typische Aufgaben der Planung und Entscheidung sind die Multiprojekt-Konﬁguration

und die Multiprojekt-Priorisierung. Neben der Zuordnung von strategischen Budgets prüft

Nutzung einheitlicher sowie objektiv gestalteter

Bewertungs- und Entscheidungsprozesse

Abstimmung von Projektvorhaben und

strategischen Budgets auf Unternehmensebene

Engpassorientierte Zuteilung von Ressourcen

zu strategischen Projekten

Sicherstellung einer adäquaten Nutzung

von Bewertungsinstrumenten

Ausrichtung der Projektpriorisierung auf

strategische Erfordernisse

Bewertung und Visualisierung aller

Projekt-Abhängigkeiten

Machtpolitische Friktionen

innerhalb der Projektauswahl

Überschreitung von

strategischen Budgets

Unzweckmässige Ressourcen-

Zuteilung zu Projekten

Fehlende Strategieorientierung

der Projekte

Nichtberücksichtigung von

Wechselwirkungen zw. Projekten

Auswahl nicht wertschöpfender

Projekte, Doppelspurigkeiten

Einrichtung einheitlicher und methoden-

gestützter Monitoring- und Reviewprozesse

Etablierung eines an den Bedürfnissen

orientierten Wissensmanagements

Verlust der Kontrolle über die

Projektgesamtheit

Verlust von projektbezogenem

Erfahrungswissen

Einrichtung einer Multiprojekt-

Führungsorganisation

Etablierung eines Multiprojekt-

Informationssystems

Fehlende organisatorische

Regelungen

Keine zeitnahen projekt- und

portfoliobezogenen Informationen

Problemfelder

Elemente

Aufgabenfelder

Multiprojekt-

Konﬁguration

Multiprojekt-

Priorisierung

Multiprojekt-

Kontrolle

Multiprojekt-

Struktur

Abb. 2.79 Problemfelder, Aufgabenfelder und Elemente Multiprojektmanagement

2.7

Projektportfolio- und Programmmanagement

241

Planung und

Entscheidung

Realisation = Projektmanagement

Multiprojekt-

Konﬁguration

Multiprojekt-

Priorisierung

Kontrolle

Multiprojekt-

Kontrolle

Strukturierung des Multiprojektmanagements

Abb. 2.80 Elemente Multiprojektmanagement

das Multiprojektmanagement auch laufend die Bewertungskriterien auf ihre Zweckmäßig-

keit und passt sie den Anforderungen an. Die Multiprojekt-Kontrolle dient der laufenden

Überwachung. In vielen Unternehmen hat sich das Projektportfoliomanagement etab-

liert. In der Multiprojekt-Struktur wird die laufende Optimierung und Anpassung der

Organisation abgebildet. Für Unternehmen, welche ein Multiprojektmanagement erst-

malig aufbauen, ist die Multiprojekt-Struktur die zentrale Aufgabe in der Startphase.

Abb. 2.80 zeigt das Zusammenspiel der Elemente des Multiprojektmanagements (Kunz

2007, S. 35).

2.7.1.2

Multiprojektmanagement-Prozess

Abb. 2.81 zeigt den idealtypischen Multiprojektmanagement-Prozess.

In einem ersten Schritt wird das Portfolio konﬁguriert. Die restlichen Schritte werden

immer wieder durchlaufen. Je nach Unternehmen wird der Multiprojektmanagement-Pro-

zess quartalsweise bis jährlich durchlaufen. Einzelne Schritte wie das Reporting können

auch in kürzeren Zyklen (z. B. monatlich) stattﬁnden. Die Periodizität hängt sehr stark

von den Projektarten ab. Unternehmen mit innovativen und agilen Projekten haben ten-

denziell kürzere Zyklen. Hingegen kann einem Unternehmen mit vielen Bauprojekten ein

quartalsweises Reporting völlig reichen.

242

Methodik

Reporting

Soll-Ist-Vergleich

Kontrolle

Planung und Entscheidung

Konﬁguration Portfolio

Projektbewertung

Priorisierte Projektliste:

Mandatory Projekte

Projekte in Umsetzung

Rangliste mit restlichen Projekten

Ideen

Projektanträge

Laufende Projekte

Inhaltliche Abhängigkeit

Ressourcenverfügbarkeit

Projektportfolio

Abb. 2.81 Idealtypischer Multiprojektmanagement-Prozess

2.7.1.3

Konfiguration des Portfolios

Bei der Konﬁguration des Portfolios sind folgende Punkte zu betrachten und festzulegen:

Dimensionieren des Portfolios: Welche Teile des Unternehmens sollen im Portfolio

abgebildet werden?

Bewertungskriterien für die Projektauswahl

Standardisiertes Reporting: Welche Informationen in welcher Periodizität?

Geeignetes Multiprojektmanagement-Informationssystem: Ofﬁce Anwendung oder ein

spezialisiertes Portfolioboard

Etabliertes Portfolioboard und geklärte Rollen

Regeln des Genehmigungsprozesses

Organisatorische Anpassungen

Wenn ein Unternehmen das Multiprojektmanagement aufbaut, sind dies die zentralen

Aufgabenstellungen. In Unternehmen mit einem etablierten Multiprojektmanagement sol-

len diese Punkte regelmäßig auf die Zweckmäßigkeit überprüft und angepasst werden.

Ist das Portfolio konﬁguriert, so sind in einem ersten Schritt die notwendigen Infor-

mationen zu Ideen, Projektanträgen und laufenden Projekten zu sammeln. Dadurch

2.7

Projektportfolio- und Programmmanagement

243

gewinnt der Multiprojektmanager die Übersicht über die geplanten und laufenden Vorha-

ben. Dies ist der erste große Schritt zu einem Portfolio. In der Praxis ist immer wieder

zu beobachten, dass Firmen keine Übersicht über ihre laufenden und geplanten Projekte

haben. Diese mangelnde Transparenz führt spätestens bei der Zuteilung der Ressourcen

zu Friktionen und Problemen.

2.7.1.4

Priorisierte Projektliste

Da Organisationen meist mehr Ideen und Wünsche haben, als sie mit den zur Verfü-

gung stehenden Mitteln und Ressourcen umsetzen können, müssen sie aus den Ideen und

Wünschen die besten und geeignetsten Vorhaben auswählen und selektionieren. Beim Be-

werten der Projekte ist die Frage zu beantworten, welches die richtigen Projekte sind:

Diejenigen, welche den größten Beitrag zur Strategie leisten?

Diejenigen, welche am dringlichsten sind?

Diejenigen, welche den größten Nutzen generieren?

Diejenigen des Auftraggebers mit der höchsten hierarchischen Stellung?

Die Fragen sind vielfältig. Es gibt unterschiedliche Einﬂussfaktoren, welche auf die

Priorität eines Projektes einwirken, wie in Abb. 2.82 gezeigt.

Projekt-

Priorität

Strategische

Bedeutung

Monetärer

Wert

Relativer

Vergleich

Politische

Motive

Projekt-

Abhängigkeiten

Projektrisiko

+ Flexibilität

Abb. 2.82 Einﬂussfaktoren auf Projekt-Priorität

244

Methodik

Tab. 2.47 Prioritätsklassen und Handlungsempfehlungen

Prioritätsklasse

Bedeutung für das Unternehmen

Handlungsempfehlung

Mandatory

Gesetzliche Auﬂagen, existenznotwe-

nig für die Organisation, zwingende

SW/HW-Updates

Vollständige Durchführung

Strategisch ausgerichtet und/oder hohe

Wirtschaftlichkeit

Vollständige Durchführung, sofern

keine andere Priorisierung aufgrund

von Interdependenzen erfolgt

Positive Wirtschaftlichkeit

Durchführung aufgrund von Ran-

kingliste unter Berücksichtigung von

Interdependenzen

Geringe oder negative Wirtschaftlich-

keit

Nicht durchführen

Für die Priorisierung von Projekten werden oft Prioritätsklassen verwendet. Tab. 2.47

zeigt eine mögliche Prioritätsklassiﬁzierung. Aus den Prioritätsklassen können Hand-

lungsempfehlungen abgeleitet werden.

Bewerten von Projekten heißt, eine eindeutige Projektpriorität ﬁnden. Diese Projekt-

priorität dient als Basis für die Entscheidungen bezüglich Budgetzuteilung und Durch-

führung eines Projektes. Mindestens für die Prioritätsklassen B und C sollte noch eine

Rankingliste erstellt werden. Dazu ist es hilfreich, die Kriterien und Gewichtungen zu deﬁ-

nieren, welche die „richtigen“ Projekte auszeichnen. Ein einheitliches Bewertungsschema

ist absolut zentral und zwingend. Die Bewertungskriterien können auch in Kategorien

zusammengefasst werden. Abb. 2.83 zeigt typische Kategorien in der Projektbewertung.

Mittels einer Nutzwertanalyse wird eine Rankingliste mit einer eindeutigen Prioritätsrei-

henfolge gebildet.

Die Tab. 2.48, 2.49 und 2.50 zeigen mögliche Bewertungskriterien für die in Abb. 2.83

genannten Kategorien. Die Bewertungskriterien sind individuell auf das Unternehmen

auszurichten. Durch das wandelnde Umfeld der Unternehmen sind diese Bewertungskri-

terien auch laufend den neuesten Umständen anzupassen.

Am Schluss der Bewertung der Projekte steht eine priorisierte Projektliste zur Verfü-

gung.

2.7

Projektportfolio- und Programmmanagement

245

Dringlichkeit

20%

Beitrag zur Strategie

40%

Wirtschaftlicher Nutzen

30%

Nicht-monetärer Nutzen

10%

Total

100%

Projekt

Prioklasse

Priorität

Mandatory

Priorität

(Nutzwertanalyse)

Abb. 2.83 Typische Kategorien in der Projektbewertung

Tab. 2.48 Bewertungskriterien für die Kategorie Dringlichkeit

Kriterium

Kein

(0 Punkte)

Klein

(1 Punkt)

Mittel

(2 Punkte)

Groß

(3 Punkte)

Mandatory – Gesetzliche/

Regulatorische/Compliance

Zwänge

Nein

–

Mandatory – Technologische

Zwänge (HW-/SW-/Security-

Updates)

Nein

–

Einführungstermin verschiebbar Um 3 Jahre

Um 2 Jahre

Um 1 Jahre

Nicht ver-

schiebbar

Stadium, in welchem sich das

Projekt beﬁndet

Idee/

Vorstudie

Konzeptphase Frühe Realisie-

rungsphase

Späte Reali-

sierungspha-

se/Einführung

246

Methodik

Tab. 2.49 Bewertungskriterien für die Kategorie Beitrag zur Strategie

Kriterium

Kein

(0 Punkte)

Klein

(1 Punkt)

Mittel

(2 Punkte)

Groß

(3 Punkte)

Beitrag zur Erreichung strategi-

sches Ziel XY

Keinen Beitrag

25 %

50 %

100 %

Reduktion der ICT Kosten

Keine Reduktion

25 %

50 %

100 %

Erhöhung der Kundenbin-

dung/Kundenzufriedenheit

Keine Erhöhung

Um < 5 %

Um 5–10 %

Um > 10 %

Erschließung neuer Märkte

Nein

–

Teilweise

Schaffung von Wettbewerbs-

vorteilen

Nein

–

Schaffung von Innovation

Nein

–

Tab. 2.50 Bewertungskriterien für die Kategorien wirtschaftlicher und nicht-monetärer Nutzen

Kriterium

Kein

(0 Punkte)

Klein

(1 Punkt)

Mittel

(2 Punkte)

Groß

(3 Punkte)

Net Present Value, NPV

Negativ

= 0

–

Positiv

Return on Investment, ROI

3 Jahre

2 Jahre

1 Jahr

< 1 Jahr

Erwarteter Nutzen/Mehrwert

Keinen

Gering

Hoch

Sehr hoch

Imagegewinn

Nein

–

Teilweise

Steigerung Attraktivität als Arbeit-

geber

Nein

–

Teilweise

Verbesserung der Qualität/

Verminderung der Fehlerquote

Keine Senkung

der Fehlerquote

Um < 5 %

Um 5–10 %

Um > 10 %

Aufbau von internem Know-how

Nein

–

Teilweise

Minimierung von Risiken/Senkung

des Risikoindexes

Keine Senkung

Um < 5 %

Um 5–10 %

Um > 10 %

2.7.1.5

Inhaltliche Abhängigkeiten

In einem nächsten Schritt sind die inhaltlichen Abhängigkeiten zwischen den Projekten

zu klären:

Was sind die Beziehungen unter den Projekten?

Welches sind die inhaltlichen Abhängigkeiten zwischen den Projekten?

Welches Synergiepotenzial existiert?

Welche Risiken entstehen aus der Summe der Projekte?

Wann ist der richtige Zeitpunkt?

Alle Projekte jetzt sofort?

– Wenn die fachlichen Abhängigkeiten und Risiken gering sind.

– Wenn die personellen und ﬁnanziellen Ressourcen es zulassen.

Wenn ein Projekt abhängig vom Ergebnis eines anderen Projektes ist, so kann dies zu

Anpassungen in der priorisierten Projektliste führen. Um die Abhängigkeiten zu analy-

2.7

Projektportfolio- und Programmmanagement

247

Geschäftsleitung

Externe

Fachbereich A

Fachbereich B

Fachbereich C

20%

40%

Projekte

Ressourcen

Abb. 2.84 Multiprojektstruktur

sieren, braucht es vertiefte inhaltliche Kenntnisse der einzelnen Projekte. Da dies in der

Praxis vielerorts fehlt, wird die Abhängigkeitsanalyse oft vernachlässigt.

2.7.1.6

Ressourcenverfügbarkeit und -abhängigkeiten

Die Ressourcenverfügbarkeit und -abhängigkeiten müssen als Nächstes geklärt wer-

den. Werden in einem Unternehmen gleichzeitig mehrere Projekte durchgeführt, die ganz

oder teilweise auf dieselben Ressourcen zugreifen, können bei personellen Ressourcen

(Spezialisten) oder speziellen Einrichtungen und Maschinen Ressourcenkonﬂikte entste-

hen. Es muss eine Multiprojektplanung durch die Ressourcenverantwortlichen, die Füh-

rungskräfte oder Fachbereichsleiter durchgeführt werden, wie Abb. 2.84 zeigt.

Die Projektleiter planen die Projekte bezüglich Tätigkeiten und Terminen (Projekt-

sicht) und geben der Linie ihren Ressourcenbedarf und ihre Wünsche bezüglich bevorzug-

ter Ressourcen mit Zeitpunkt bekannt. Der Linienverantwortliche, der über die Ressourcen

verfügt, muss die Bedürfnisse aller Projekte zusammenﬂießen lassen in einer Ressour-

ceneinsatzplanung über alle Projekte und alle Ressourcen, für die er verantwortlich ist.

Zusätzlich berücksichtigt er alle Grundlasten für jeden Mitarbeiter: Linienaufgaben, Ab-

wesenheiten, Nebenaufgaben usw. Der Einsatzplan, den die Linie für jeden Mitarbeiter

248

Methodik

erstellt, stellt alle Aufgaben dieses Mitarbeiters über alle Projekte dar, in die er involviert

ist.

Im Multiprojektmanagement kann die Ressourcenverfügbarkeit auch in einer Gegen-

überstellung von benötigten und verfügbaren personellen Ressourcen über alle Fachberei-

che erfolgen. Dabei werden die Über- oder Unterbelastungen der einzelnen Mitarbeiter

eruiert.

Unabhängig davon, ob die Überprüfung der Ressourcenverfügbarkeit und -abhän-

gigkeiten auf Ebene des Fachbereichs oder auf Ebene der ganzen Organisation erfolgt,

geht es um die Frage, ob die richtigen personellen Ressourcen in genügendem Masse vor-

handen sind.

2.7.1.7

Das Projektportfolio

Die Berücksichtigung der inhaltlichen Abhängigkeiten und der Ressourcenverfügbarkeit

und -abhängigkeiten führen zu Anpassungen in der priorisierten Projektliste. Das Ergebnis

stellt dann das Projektportfolio dar, welches umgesetzt werden soll.

Das Projektportfolio ist eine Übersicht über alle vorhandenen Projekte, welche in Form

einer strukturierten Liste oder graﬁsch – nach unterschiedlichen Kriterien geordnet –

dargestellt werden. Dabei ist die Organisation frei, nach verschiedenen Projektarten zu

unterscheiden, etwa interne und externe, kurz- und langfristige, hochkomplexe und stan-

dardisierte oder Kunden- und Infrastrukturprojekte.

Für die graﬁsche Darstellung werden die Projekte oft anhand von zwei wichtigen Be-

wertungskriterien dargestellt, siehe Abb. 2.85. Je nach Natur der Vorhaben genügt dazu

bereits eine Aufschlüsselung in duale Kriterien-Paare, wie z. B. Chancen vs. Risiken, Kos-

ten vs. Nutzen. Häuﬁg werden mehrere solche Sichtweisen über ein und dasselbe Projekt

erstellt. Ein Projektportfolio kann aber auch mehrdimensional aufgebaut werden bezüg-

lich:

Beitrag zur Strategieumsetzung

Dringlichkeit

Ökonomischer Kriterien (Kennzahlen, Markt)

Ökologischer Kriterien

Chancen/Risiken

Muss-Kriterien (Neue Gesetze, Technologiesprünge)

Wie in Abb. 2.85 gezeigt, können die Kosten der Projekte über die unterschiedliche

Größe der Fläche des dargestellten Projektes visualisiert werden.

2.7.1.8

Reporting

Das Reporting im Multiprojektmanagementprozess hat den Fokus auf der Gesamtheit der

laufenden Projekte und basiert auf dem Controlling in den einzelnen Projekten (siehe

Abschn. 2.5.6 und 2.5.7). Das Reporting hilft, das Projektportfolio zu steuern und Hand-

lungsbedarf zu identiﬁzieren. Das Reporting kann wie folgt gegliedert werden:

2.7

Projektportfolio- und Programmmanagement

249

Kriterium 1

Kriterium 2

P10

Abb. 2.85 Beispiel Projektportfolio

Fortschrittskontrollen: Project on Track?

Ergebniskontrollen: Wurden die Ziele erreicht?

Reviews: Stimmen die strategische Ausrichtung und Prioritäten noch?

Für die Fortschrittskontrolle werden auf der Ebene des Projektportfolios beispiels-

weise die Monats-Reportings der einzelnen Projekte konsolidiert, wie in Abb. 2.86 ge-

zeigt.

Die Ergebniskontrolle erfolgt in einem ersten Schritt auf der Ebene Projekt. Beim

Projektabschluss wird geprüft, ob die gesetzten Ziele erreicht wurden und die geplan-

te Wirkung eingetreten ist. Auf Ebene Multiprojektmanagement werden die Ergebnisse

konsolidiert und zusammengeführt.

Reviews haben das Multiprojektmanagement selber im Fokus und ﬁnden quartalswei-

se, halbjährlich oder jährlich statt. Dabei geht es um die Überprüfung der strategischen

Relevanz der Multiprojekt-Konﬁguration und um die Identiﬁkation eines allfälligen An-

passungsbedarfs. Weiter sollen auch die Bewertungskriterien für die Priorisierung über-

prüft werden.

250

Methodik

Stand: 01.10.2018

Projektname

Start

Ende

Aktuelle Phase

Sept

Okt

Scope

Zeit

Kosten

Risiken

Qualität

Belﬂower

5-2018

1-2019

04 - Realisierung

Dandelion

10-2018

3-2019

01 - Beauragung

Edelweiss

1-2016

4-2020

04 - Realisierung

Hibiskus

10-2017

4-2020

02 - Inialisierung

Lily

12-2017

4-2018

05 - Einführung

Rose

1-2011

5-2019

04 - Realisierung

Tulip

9-2017

6-2018

05 - Einführung

Violet

4-2017

6-2019

04 - Realisierung

on track

PL Eskalaon

GL Eskalaon

abgeschlossen

Abb. 2.86 Beispiel eines Monats-Reportings auf Portfolioebene

2.7.1.9

Stufen zu einem exzellenten Portfoliomanagement

Der Aufbau des Portfoliomanagements erfolgt in Stufen und dauert mehrere Jahre.

Tab. 2.51 zeigt die möglichen Stufen im Aufbau eines exzellenten Portfoliomanagements.

Um die Stufe der Exzellenz zu erreichen, sind unter anderem folgende kritischen Er-

folgsfaktoren zu berücksichtigen:

Kriterien und Methoden müssen auf das Unternehmen angepasst sein: Was ist wichtig?

Priorisierungssystem liefert klare und eindeutige Lösungen

Einheitliche und über längeren Zeitraum stabile Projektbewertungsmethodik/-kriterien

Priorisierungssystem ist transparent und von allen Beteiligten nachvollziehbar

Datenqualität ist Voraussetzung für ein gutes Ergebnis

Deﬁnierter und gelebter Prozess für das Multiprojektmanagement

Unterstützung durch das Top-Management

2.7.2

Programmmanagement

Ein Programm ist die Gesamtheit von miteinander verbundenen Projekten und organi-

satorischen Änderungen. Ein zentrales Element ist die konsequente Ausrichtung eines

Programms an einer übergeordneten Strategie (Neustrategie oder periodische Überar-

beitung der Strategie). Das Programm wird als Instrument verwendet, um der Strate-

gieumsetzung mehr Schub zu geben. Dem gegenüber streben Linienorganisationen nach

Stabilität und einer kontinuierlichen Mitarbeiterentwicklung. Sie richten sich nach zeitlich

länger dauernden KVP-Prozessen aus.

Durch die Bündelung von Projekten unter einer Programmmanagement-Führung er-

hofft man sich eine signiﬁkante Verbesserung in der Planung, Priorisierung, Durchführung

2.7

Projektportfolio- und Programmmanagement

251

Tab. 2.51 Stufen zu einem exzellenten Portfoliomanagement

Stufe

Ziel

Leistungen

Aktivitäten

Realisierungs-

dauer

Information

– Transparenz

– Übersicht

– Gesamtsicht der

laufenden und

geplanten Projekte

– Grund-Auswertun-

gen zum Portfolio

(Kosten, Fort-

schritt)

– Gemeinsame Pro-

jekt-Eckdaten

– Einheitliches Re-

porting

– Einheitliches Ab-

wicklungsraster für

Projekte

Nach 0,5–

1,5 Jahren

Methoden

+ Prozesse

– Harmonisierte

und durch-

gesetzte

Vorgehenswei-

sen, Methoden

und Tools

– Nachvollziehbare

Bewertungen von

Ideen/Projekten

– Analyse von Pro-

jekt-Beziehungen

– Portfolio-Re-

porting mit

Empfehlungen

– Projekt-Entsteh-

ungs- und Re-

porting-Prozesse

vereinheitlichen

– Methoden einfüh-

ren

– Funktionsfähige

Organisations-

Einheit bilden

(Rollen deﬁnieren)

Nach 2–3

Jahren

Exzellenz,

Strategieori-

entierung

– Aktiv gesteuerte

Projekt-Land-

schaft

– Nachweise der

Wirksamkeit über

Kennzahlen

– Dedizierte Aus-

wertungen zu

Aufwand und Wir-

kung

– Planungsrelevante

Analysen für alle

Stakeholder

– Projekt- und

Ressourcen-

management

integrieren

– Strategieprozess

verbinden/

integrieren

– KVP betreiben

Nach > 4

Jahren

und Steuerung der Vorhaben gegenüber der Vorgehensweise, diese Projekte individuell

abzuwickeln.

2.7.2.1

Was kennzeichnet ein Programm?

Programme haben, wie Projekte, einen Anfang und ein (geplantes) Ende: Initialisierung,

Durchführung und Abschluss.

Ein Programm bezieht sich auf eine oder mehrere strategische Zielsetzungen. Es hat

eine Mission und Vision. Die Bezugnahme zur Strategie ist ein essentielles Bildungskri-

terium für Programme.

Bei Programmstart sind die zum Programm gehörenden Projekte evtl. noch nicht voll-

ständig deﬁniert – in der Initialisierungsphase entsteht hingegen eine generelle grobe

Roadmap für das Programm.

Es ist notwendig, die Eignung (Projektbewertung) einzelner Projekte innerhalb des Pro-

gramms im Hinblick auf die Strategie kontinuierlich zu überprüfen.

252

Methodik

Die Projekte und ihre konkretisierten Ziele sowie Anforderungen müssen sich immer

an den zum Programm gehörenden strategischen Zielsetzungen orientieren. Projekte in-

nerhalb eines Programms haben inhaltliche und zeitliche Bezüge untereinander. Spätere

Projekte innerhalb des Programms sind abhängig von den Ergebnissen früherer Projekte.

2.7.2.2

Mehrwert der Programmorganisation

Die Einführung einer Programmorganisation muss einen Mehrwert bringen. Folgende

Mehrwerte (Treiber) erhofft man sich von Programmen:

Das Programm steuert ein Thema fachlich und schafft eine Kohärenz zur Thematik.

Die Bildung von Programmen führt zu einer transparenteren Planung und Steuerung,

insbesondere der ﬁnanziellen Prozesse: Top Down, konsequente Ausrichtung auf stra-

tegische Zielsetzungen, „Herunterbrechen“ von Zielsetzungen.

Die Qualität der Projektdeﬁnitionen sollte besser sein im Sinne einer besseren Ausrich-

tung der Projektziele, der Leistungen und deren erhofften Wirkungen auf die strategi-

schen Handlungsfelder.

Die Bedeutung einzelner Projekte innerhalb des Programms im Hinblick auf die Stra-

tegie wird kontinuierlich überwacht.

Bei notwendigen Entscheiden zu Priorisierungen von Projekten innerhalb des gleichen

Programms wird die Entscheidung weggezogen von primären Linieninteressen („das

ist wichtig“) und hin zur konsequenten Ausrichtung und Bewertung des Beitrags zur

Erreichung der strategischen Zielsetzungen geführt.

Ein weiterer Vorteil liegt in der standesgerechten Entscheidungshierarchie:

Die Geschäftsleitung bestimmt Strategie und Mittel.

Das Programm behält auf taktischer Ebene die angestrebten Ziele im Auge.

Die Projekte haben, einmal deﬁniert, einen vorwiegend operativen Fokus.

2.7.2.3

Unterscheidung Projekt- und Programmmanagement

Die Tab. 2.52 zeigt die Unterschiede zwischen Projekt- und Programmmanagement auf.

2.7.3

Project Management Office – PMO

Immer mehr Organisationen sehen die Notwendigkeit, ihr Projektgeschäft gesamthaft zu

managen, zu steuern und zu überwachen. Die Auslöser dazu reichen von der Steuerung

des Programmmanagements und der Multiprojektplanung, vom Wettbewerbsdruck über

die Pﬂicht zum Nachweis der wirtschaftlichen und wirksamen Verwendung von Mitteln

bis hin zur Steuerung der Arbeitslast der Mitarbeiter, um deren Überlastung und Burnout

zu vermeiden.

2.7

Projektportfolio- und Programmmanagement

253

Tab. 2.52 Projektmanagement versus Programmmanagement

Charakteristik

Projekt

Programm

Änderungen

Ein Projekt versucht tendenziell Än-

derungen zu minimieren ( Termin,

Kosten, Qualität).

Ein Programm erwartet Änderungen und

geht auf diese ein, sofern sie im Hinblick

auf die Erreichung der strategischen

Ziele erfolgversprechend erscheinen.

Führungsstil

Hauptaugenmerk liegt auf der Ab-

wicklung des Projektes und der

Erstellung der deﬁnierten, vertrag-

lich zugesicherten Lieferobjekte.

Hauptaugenmerk liegt auf dem Bezie-

hungsmanagement und der Lösung

allfälliger Konﬂiktsituationen wie Pro-

jektabhängigkeiten, Programm/Linie,

Interessenkonﬂikte, Ressourcenzutei-

lung, Kapitalbedarf.

Management-

stil

„Teamplayer“, welcher seine Fä-

higkeiten und sein Know-how

hauptsächlich zur Team-Motivati-

on einsetzt.

Überblick bewahren, Akzent auf Mission

und Vision des Programms legen.

Monitoring

Sicht nach innen ins Projekt.

Sicht zwischen den Projekten sowie

zu den Schnittstellen zu Projekten

außerhalb. Sucht systematisch nach Syn-

ergiepotenzial respektive das Programm

gefährdenden Risiken.

Planung

Detaillierte Arbeitspaketplanung,

Ressourcenzuordnung, etc.

Roadmaps sowie Handlungsvorschrif-

ten für Projektleiter bezüglich Planung

(ähnlich wie QS-Vorgaben, Risikoma-

nagement usw.).

Scope

Üblicherweise wird ein wohl de-

ﬁnierter, eingeschränkter Scope

verfolgt, fokussiert auf die in-

haltliche, organisatorische und

beziehungsmäßige Abwicklung des

zugewiesenen Projektes.

Scope auf Programmebene ist breiter und

kann Änderungen erfahren, um strategi-

sche Zielsetzung zu erreichen.

Erfolg

Kundenzufriedenheit

Termin, Kosten, Qualität

Return on Investment (ROI), KPI, Er-

reichen des strategischen Ziels oder

zumindest Wirkungsnachweis.

Eine solche Stabfunktion der Geschäftsleitung, welche diese Aufgaben erledigt, wird

mehrheitlich Project Management Ofﬁce (PMO) genannt. Andere gebräuchliche Namen

sind auch „Projektbüro“ oder „Competence Center Project Management“. Die jeweiligen

Aufgaben, Verantwortungen und Befugnisse eines PMO können unterschiedlich weit de-

ﬁniert sein. Je zentraler die Managementfunktionen des Projektmanagements im PMO

zusammengeführt werden, desto mächtiger und steuernder für die ganze Organisation

wird es. Im Idealfall wird es das Unterstützungs- und Kompetenzzentrum für Projekte und

deﬁniert, wie Projekte, Programme, Projektportfolios und das Tagesgeschäft einer Orga-

nisation aufeinander abgestimmt und mit möglichst großer Wirksamkeit gesteuert werden

254

Methodik

können. Je nach Reifegrad der Organisation werden Funktionen und Aufgaben von einem

PMO geleistet. Diese lassen sich in vier Kernfunktionen zusammenfassen:

Unterstützungsfunktion: Unterstützung für die einzelnen Projekte in der operativen

Projektarbeit, z. B. Projektdokumentationen und Berichte verfassen und andere klassi-

sche Back-Ofﬁce-Aufgaben.

Beratungsfunktion: Projektleiter und -mitarbeiter beraten, coachen und trainieren,

Prozessstandards deﬁnieren und pﬂegen, Methoden und Tools bereitstellen

Koordinationsfunktion: Schnittstellen- und Kommunikationsmanagement (Termine,

Inhalt und Umfang, Synergien). Hierzu gehört die Ressourcenkoordination zwischen

der Linie und den Projekten (siehe auch Abschn. 2.7.1.6 Multiprojektmanagement).

Governance-/Regulierungsfunktion:

Strategisches

Projektportfolio-Management

und Projektportfolio-Steuerung bewirtschaftet die Projekt-Priorisierung und Ge-

nehmigung des Projektportfolios und das Projektcontrolling in einem Multiprojekt-

Unternehmen.

2.7.4

Projektmanagementhandbuch

Ein projektorientiertes Unternehmen erstellt sinnvollerweise eine Projektmanagement-

Richtlinie in Form eines Handbuches, welches die für alle Projektabwicklungen geltenden

Regeln deﬁniert und verbindlich erklärt. Die Projektmitarbeiter werden diese Projekt-

kultur dann am schnellsten übernehmen und leben, wenn sie die Regeln nachvollziehen

können und das ganze Dokument als Hilfe empﬁnden. Das ist dann der Fall, wenn das Do-

kument schlank und einfach verständlich ist, die Mitarbeiter bei der Erstellung beigezogen

wurden und auch nützliche Hilfsmittel angeboten werden z. B. Vorlagen, Instrumente und

Checklisten.

Bei komplexen Projekten sind diese Vorgaben vollumfänglich und strikt einzuhalten.

Bei kleinen Routineprojekten werden die Schritte den unternehmerischen Bedürfnissen

angepasst und skaliert angewendet. Für wichtige Projekte kann eine an die Projektbedürf-

nisse angepasste Form erstellt werden gemäß Abschn. 2.3.13. Das Projektmanagement-

handbuch gilt unternehmensweit. Das Projekthandbuch gilt speziﬁsch für ein einzelnes

Projekt.

Mögliche Themen in einem Projektmanagementhandbuch sind:

Geltungsbereich

Deﬁnition „Projekt“

Projektarten (Organisation, ICT, Produktentwicklung, Infrastruktur)

Projektkategorien (Strategisch, International, Klein-Projekte)

Übersicht der Prozesslandschaften, Wertschöpfungskette, Phasenplan, Meilensteine,

Reviews, Freigaben, klassische und agile Vorgehensweise

Beschreibung der Tätigkeiten, zugehörende Dokumente

2.8

Lösungsfindung

255

Projektorganisation, Teamzusammensetzung, Steuerungsgremien

Zuständigkeiten, Verantwortlichkeiten, Kompetenzen

Stakeholder-Analyse, Funktionendiagramm, Eskalationswege

Planung der Termine und Kosten, Multiprojektmanagement

Information, Kommunikation

Change Request Management

Handhabung der Risiken

Projektcontrolling, Kosten- und Terminüberwachung, Berichterstattung

Projektabschluss

Mitgeltende Dokumente, Tools, Templates, Checklisten

Know-how-Transfer, kontinuierlicher Verbesserungsprozess

Zusammenarbeit Linienorganisation/Projektorganisation

Kompetenzen, Verantwortlichkeiten, Projektleiterkarriereplanung

Glossar

2.8

Lösungsfindung

2.8.1

Kreativitätstechnik, Lösungsfindung und Lösungsauswahl

Die Lösungssuche folgt auf die Zielformulierung und ist der spielerisch-kreative Teil eines

Problemlösungsprozesses. In diesem Schritt des Lösungsﬁndungsprozesses ist eine Reihe

von Varianten zu ﬁnden. Die Tauglichkeit der Lösungsideen wird danach geprüft. Die bes-

ten Varianten werden schließlich in einer systematischen Gegenüberstellung bewertet. Die

Methoden der Lösungsﬁndung werden in der klassischen Vorgehensweise hauptsächlich

in der Konzeptphase und in der agilen Vorgehensweise hauptsächlich in der Realisierungs-

phase angewandt.

Das Projektteam soll in der kreativen Phase der Lösungssuche eine bewusste Abstrak-

tion vom realen Projektumfeld und dessen Rahmenbedingungen vornehmen, um nicht in

„altbekannte“ Lösungsmuster zu verfallen. Je komplexer die Problemstellung ist, umso

vielseitiger müssen verschiedene Techniken und Denkweisen angewendet und kombiniert

werden, um eine gute Lösung zu ﬁnden.

2.8.1.1

Ohne Neugierde keine Kreativität

Kreativität ist die Fähigkeit des Menschen, Denkergebnisse beliebiger Art hervorzubrin-

gen, die im Wesentlichen neu sind und demjenigen, der sie hervorgebracht hat, vorher

unbekannt waren. Kreativität braucht vor allem Intuition, Intelligenz ist sekundär. Vie-

le kreative Lösungen werden unbewusst vorbereitet. Der Moderator soll in dieser Phase

ein Klima schaffen, das die Selbständigkeit der Teammitglieder und den Spaß am Fin-

den neuer Ideen fördert. Die Projektziele sollen die Emotionen ansprechen und damit die

Neugier des gesamten Projektteams anstacheln. Abb. 2.87 zeigt Fragen zur Aktivierung

der Lösungssuche.

256

Methodik

Was lässt sich ändern, umdrehen,

auf andere Art anordnen?

• Bedeutung

• Wirkung

• Farbe, Aussehen

• Klang, Lautstärke

• Bewegung, Gangart, Antrieb

• Material, Technologie

Was lässt sich vermindern?

• weglassen

• ausschalten

• aufteilen

• konzentrieren

• bewusst mildern

• abschwächen

• leichter machen

• verkleinern

Was lässt sich kombinieren?

• kombinieren

• mischen

• verteilen

• sortieren

• parallel, seriell

Abb. 2.87 Fragen zur Aktivierung der Lösungssuche

2.8.1.2

Möglichkeiten, kreativ zu werden

Kreativität wird häuﬁg durch Blockaden behindert, siehe Tab. 2.53. Solche Blockaden

werden meist unbewusst von uns selbst oder aber durch äußere Einﬂüsse und ungünstige

Umstände geschaffen oder verstärkt.

Blockaden können teilweise überwunden, die Kreativität kann positiv beeinﬂusst wer-

den durch:

ein arbeitsfähiges, spannungsarmes Team

eine ungezwungene Arbeitsatmosphäre

klare Aufgabenstellung und Zielvorstellung

die Fähigkeit, ein Urteil aufschieben zu können

verschiedene Perspektiven, Optiken, Standpunkte

Erlaubnis, Dinge auf den Kopf zu stellen

Arbeiten mit Analogien aus der Natur

Zulassen von Phantasien und Bildern

Visualisierung aller Beiträge bzw. Ideen

Verwendung des Zufalls

2.8

Lösungsfindung

257

Tab. 2.53 Blockaden der Kreativität

Physische und umweltbedingte

Blockaden

Soziologische Blockaden

Psychologische Blockaden

Umgebung

– Schlechter Arbeitsplatz

– Schlechte/mangelhafte

Arbeitshilfsmittel

– Lärm, Temperatur

– Anrufe, Störungen

– Ungünstiger Zeitpunkt

Beﬁndlichkeit

– Ermüdung

– Angegriffene Gesundheit

– Burnout

– Stress

Kulturell

– Mangel an Anerkennung

– Tabus, Sitten, heilige Kühe

– Kulturelle Muster

– Mentalität

Gruppenarbeit

– Zusammenspiel

– Konﬂikte, Spannungen

– Rivalität

– Ausgeprägter Wettbewerb

– Entmutigung und Kritik

– Zu viele Teilgruppierungen

Management, Politik

– Zu starre oder strenge insti-

tutionelle Kontrollen

– Reglementierung der

Kommunikation

– Bürokratie

– Keine Wertschätzung für

kreative Arbeit

– Einseitige Tätigkeit

– Zu viele Routinearbeiten

– Über-Administration

– Formalismus

Verschlossenes Denken und

geistige Starrheit

– Konformismus

– Funktionelle Fixation

– Ablehnung neuer Ideen

– Gewohnheiten

Kognitive Dissonanzen

– Autoritätsabhängigkeiten

– Furcht vor Änderungen

– Angst vor Risiko

– Vorgefasste Meinungen

– Perfektionismus, Suche nach

dem Absoluten

– Widersprüchliche Ziele

Motivation

– Angst vor dem totalen

Engagement

– Enttäuschung in der Arbeit

– Unentschlossenheit

– Mangel an Selbstvertrauen

– Mangel an Neugier

– Mangel an Sicherheiten

– Psychologische Sättigung

– Anspruchslose Ziele

Um das für die Erarbeitung von Lösungsideen vielfach notwendige Potenzial unse-

rer Kreativität zu erschließen, sind verschiedene Kreativitätstechniken entwickelt worden.

Sie werden angewendet, wenn keine Routinelösungswege bekannt sind. Dabei werden

intuitiv-kreative Methoden und analytisch-systematische Methoden unterscheiden. Meist

werden in einem Lösungsprozess – je nach Detaillierungsstufe – mehrere Techniken nach-

einander angewendet.

Ein kreativer Prozess läuft in drei Phasen ab, siehe Abb. 2.88. Diese können ﬂießend

ineinander übergehen. Sicher braucht es eine Aufwärmzeit, eine logische Phase, damit

ein Team in der folgenden intuitiv-kreativen Phase Höchstleistungen erbringen kann. Eine

sportliche Höchstleistung gelingt auch nur mit richtigem Aufwärmen.

2.8.1.3

Brainstorming

Brainstorming wurde in den 1940er Jahren vom Amerikaner A. F. Osborn entwickelt mit

dem Ziel, den Strom der Ideenerzeugung in einer Problemlösungskonferenz ungehindert

produktiv und effektiv ﬂießen zu lassen. Er trennte den Kreativitätsprozess von der sofor-

tigen Diskussion der Tauglichkeit der jeweiligen Ideen ab.

258

Methodik

Intuitive

Phase

Kritische

Phase

Idee wird auf ihre Brauchbarkeit und Realisierbarkeit überprüft

Problem verstehen und abgrenzen, intensive Beschäftigung mit

dem Problem, Wissen ansammeln

Aufbruch zu neuen Lösungsansätzen, Abstand vom bekannten

Problem, Abstand von bekannten Problemlösungen

Erste Lösungsansätze im bekannten Bezugssystem

Die Lösungsideen werden plötzlich in ihrer Gesamtheit bewusst

Logische

Phase

Problemstellung

Vorbereitung

Kreativer Prozess

Abb. 2.88 Ablauf eines kreativen Prozesses. (Szichos 1993)

Vorbereiten

Heterogene, das System repräsentierende Gruppe zusammensetzen (fünf bis zwölf Per-

sonen)

Moderator und „Sekretär“ bestimmen zum Aufschreiben der Ideen

Thema bestimmen

Produktives Arbeitsklima schaffen (Umgebung)

Eventuell Zeit festlegen (20–30min)

Regeln bekannt geben: Keine Kritik, auch keine nonverbale Kritik (Bewertung kommt

später), Quantität vor Qualität, der Phantasie freien Lauf lassen

Durchführen

Problem klar formulieren

Ideen laufend für alle sichtbar aufschreiben

Ideen spontan äußern lassen; nicht diskutieren; nicht kritisieren; bei Kritik eingreifen

Ungewöhnliche Ideen willkommen heißen, Ideenklau ebenfalls!

Nach erster Ermüdung neue Impulse geben

2.8

Lösungsfindung

259

Zeit

Ideen

Stille aushalten,

Abstand, neue

Impulse geben

bekannt

verrückt

Abb. 2.89 Brainstorming

Auswerten

Ideen gruppieren

Ideen bewerten und unbrauchbare ausscheiden

Brauchbare Ideen weiter konkretisieren

Bei anspruchsvollen Themen die Ideen den Fachspezialisten zur Bearbeitung überge-

ben

Der Gruppe Feedback geben, was aus den Ideen geworden ist

Es hat sich in der Praxis als hilfreich erwiesen, nach der Phase der ersten Ermüdung

durch den Moderator Impulse zu geben, um in einer zweiten Welle die im Sinne des

Wortes ver-rückten Ideen aufzuspüren (Abb. 2.89).

2.8.1.4

Analogie: Bionik und Synektik

Methoden der Analogie nutzen die erkennbare Ähnlichkeit in Form, Eigenschaft oder

Funktion zweier Phänomene, wie in Tab. 2.54 gezeigt. Die Analogie liegt zwischen Iden-

tität (vollständige Gleichheit) und Diversität (vollständige Verschiedenheit). Die Bionik

sucht Lösungen, indem Vorbilder in der Natur untersucht und nachgebaut werden. Die

260

Methodik

Tab. 2.54 Vorgehensschritte der Analogiemethode

1. Schritt

Gewollte Eigenschaft bzw. Funktion festlegen

2. Schritt

Vorbilder suchen, die ähnliche Eigenschaften bzw. Funktionen aufweisen

3. Schritt

Das System untersuchen, das diese Eigenschaft bzw. Funktion besitzt oder hervor-

bringt

4. Schritt

Prüfen, ob und wie die Wirkungsweise übertragbar ist

Synektik versucht durch verfremdende Analogiebildung die Intensität der Lösungssuche

noch zu steigern.

2.8.1.5

Lösung herstellen

Eine Lösung herstellen kann in der Informatik heißen, das Programm zu codieren. Bei

einem Bauprojekt fahren jetzt die Bagger auf, während in der Konsumgüterindustrie die

Produktionsmittel beschafft werden müssen. Die drei Beispiele zeigen, dass menschliche

Arbeit nötig ist, um ein Projekt in dieser Endphase verwirklichen zu können.

Oft ist die erste Realisierung der Lösung mit einem Prototyp von Vorteil: Das Funkti-

onsmuster wird in einen Prototyp umgesetzt. Jetzt – und in einem weiteren Ausmaß mit

der Nullserie – können sowohl die technisch perfekt funktionierende Lösung als auch der

Umgang damit erprobt werden. Die Herstellung der Nullserie zeigt auf, ob der Produkti-

onsprozess beherrscht wird. Wo Projekte vom Benutzer verlangen, dass er sein Verhalten

ändere, können Widerstände mit einem Versuch abgebaut werden. Der Umgang mit der

neuen Lösung kann so eingeübt und die Vorteile können erfahren werden.

2.8.1.6

Lösungstest

Bevor eine Produktion in Serie geht, muss ein Härtetest, z. B. an einer Nullserie durchge-

führt werden. Die Lösung wird am Anforderungskatalog gemessen:

Erfüllt die Lösung die gesetzten Ziele und Anforderungen?

Erfüllt sie auch ungeschriebene Anforderungen?

Können die Bedingungen an die Lösung erfüllt werden, die sich erst im Betrieb mani-

festieren?

Beherrscht das Unternehmen die Produktion?

Ein isolierter Testlauf einzelner Teile der Lösung garantiert die Praxistauglichkeit noch

nicht. Um komplexe Systeme testen zu können, müssen diese in einer Integrationsphase

zuerst in einer sinnvollen Reihenfolge zusammengebracht und in Betrieb genommen wer-

den. Häuﬁg nimmt die anschließende Fehlersuche einen längeren Zeitraum in Anspruch

als geplant. Bis zur Funktionsfähigkeit ist das Zusammenspiel der einzelnen Funktio-

nen zu beurteilen, ebenso der Umgang des Benutzers mit dem neuen System. Besonders

hilfreich sind Erfahrungen von kritischen Benutzern und von solchen „mit zwei linken

Händen“. Die Ergebnisse aus den Pilotanlagen und der Nullserie zeigen, wie gut die Qua-

litätsziele erreicht werden.

2.8

Lösungsfindung

261

2.8.1.7

Lösungssuche: Optimierung

Ideenmanagement

Ideen haben die unangenehme Eigenschaft, dass sie leicht vergessen werden. Jede Orga-

nisation ist gut beraten, mit einem aktiven Ideenmanagement die guten Einfälle zu kanali-

sieren. Die Anforderungen an ein Ideenmanagement sind stark von der Branche abhängig.

In der chemischen Industrie kommt es auf ein gutes Verständnis der Produktkomponenten

und der Anforderungen an die Anwendungen an, während Dienstleistungsﬁrmen erkennen

müssen, womit sie bei ihrer Kundschaft einen noch größeren Nutzen erzielen können. In

jeder Branche legt die Unternehmensstrategie die Geschäftsfelder fest. Geschäftsfelder be-

schreiben die verschiedenen Kombinationen von Produkten und Dienstleistungen mit dem

Markt. Innerhalb der Geschäftsfelder oder auch Geschäftsfelder übergreifend beschreiben

Suchfelder den konkreten Handlungsbedarf bezüglich verschiedener Kundengruppen. Die

Fragen lauten hier: Was ist das Besondere an einer Zielgruppe? Was können wir für sie

verbessern? Suchfelder erleichtern es, Ideen gezielt zu sammeln, aufzubereiten und zu

bewerten. Positiv bewertete Ideen werden weiterverfolgt.

Variantenbildung

Projekte zeichnen sich dadurch aus, dass sie nicht linear einer einzigen Lösung nachgehen,

sondern immer mehrere Varianten zur Auswahl vorlegen. Die vielen entstandenen Ideen

sollen zu verschiedenen Varianten verdichtet werden. Durch die Kombination bekannter

Teillösungen ist es möglich, geeignete Lösungsvarianten zu bilden. Die mögliche Anzahl

Varianten sollte das Projektteam auf Grundlage seines Fachwissens bereits einschränken.

Ziel der Variantenbildung ist die Erweiterung des Lösungsraumes. Damit werden sys-

tematisch nicht zufriedenstellende Teillösungen verbessert, Lösungen nach bestimmten

Kriterien optimiert (z. B. Kosten, Gewicht), „alle“ denkbaren Lösungsmöglichkeiten zu

einem Problem gefunden und Entscheidungen durch Erschließung des Lösungsraumes

abgesichert.

In der Konzeptphase der klassischen Vorgehensweise werden die übergeordneten Lö-

sungskonzepte in mehreren Lösungsvarianten ausgearbeitet. Bei großen Projekten emp-

ﬁehlt sich, Groblösungen vom Auftraggeber bestätigen zu lassen, bevor die dazu nötigen

Detaillösungen für die Realisierungsphase vorbereitet werden. Die Gestaltung von Pro-

dukten und Prozessen wird durch die zunehmende Transparenz und Globalisierung der

Märkte zunehmend kundenspeziﬁscher. Viele Produkte werden in Varianten angeboten.

Im Verbesserungsmanagement ist eine zusätzliche Betrachtung des Produktlebenszyklus,

d. h. von Produktnutzungsumständen (z. B. Wissen aus der Reklamationsbearbeitung) und

des Produktionskontextes (Produkte, Prozesse und Anlagen) in der Variantenbildung ein-

zubeziehen.

262

Methodik

2.8.1.8

Lösungssuche: Lösungen analysieren

Die Lösungsideen zu den einzelnen Funktionen sind erst Teillösungen, da die einzelnen

Funktionen Teilprobleme sind. Erst aus der Kombination von Lösungsideen für alle Teil-

probleme ergeben sich neue Gesamt-Lösungsvarianten.

Mit Kreativitätsmethoden entsteht eine große Zahl von möglichen Lösungsvarianten,

auch ausgefallene oder unmögliche. Nicht alle Ideen-Kombinationen sind als Lösungs-

varianten für eine Weiterverarbeitung sinnvoll. Es braucht vorab eine Grobselektion oder

Ausﬁlterung einer beschränkten Zahl von guten, brauchbaren Varianten. Mögliche Hürden

für einzelne Varianten könnten z. B. sein:

Eine Variante erfüllt mit Sicherheit ein Ausscheidekriterium nicht

Eine Variante ist eindeutig zu teuer gegenüber einem Kostenziel

Die Realisierung einer Variante dauert zu lang gegenüber dem Terminziel

Eine Variante ist „psychologisch oder politisch“ ungeschickt oder unbrauchbar

Für eine sinnvolle Lösungswahl braucht es mindestens zwei Varianten, wobei eine auch

die bestehende heutige Lösung – die „Null-Variante“ – sein kann.

Morphologischer Kasten

Nach der Grobselektion bleiben brauchbare Teile für eine neue Lösung. Eine wirkungs-

volle Methode, um zu erstaunlichen Kombinationen zu kommen, hat der Schweizer Astro-

physiker Fritz Zwicky entwickelt: Der Morphologische Kasten. Er verbindet die gefunde-

nen Teillösungen in zahlreichen Variationen zu möglichen Gesamtlösungen. Die Abb. 2.90

zeigt an einem Beispiel die Idee dieser Methode.

In der vordersten Spalte links werden die Teilprobleme, Eigenschaften, Funktionen

oder auch Teilobjekte (Parameter genannt) notiert. Auf der horizontalen Achse werden

für jedes Teilproblem oder Teilobjekt Lösungsideen (Teillösungen) eingetragen oder mit

einer Skizze angedeutet. Das Aufstellen eines morphologischen Kastens ist zwar etwas

zeitaufwändig aber eine der besten Methoden zum Entwickeln neuer Lösungen. Die sys-

tematische schriftliche Matrix lässt auch zu, später den Kreativitätsprozess nachzuvollzie-

hen und so die einzelnen Teilschritte zur besten Gesamtlösung zu optimieren.

2.8.2

Lösungen bewerten und entscheiden

2.8.2.1

Nutzwertanalyse und Kosten-Wirksamkeitsanalyse

Eine Entscheidungssituation stellt für die meisten Menschen häuﬁg eine Barriere dar:

„Entscheiden“ bedeutet, verschiedene Alternativen zugunsten einer möglichen gewählten

Variante aufzugeben, sich von ihnen zu trennen. Zudem können trotz sorgfältiger Situa-

tionsanalyse andere unternehmerische Gesichtspunkte, die außerhalb der Wahrnehmung

der Projektleitung liegen, starken Einﬂuss auf die Entscheidungsﬁndung ausüben.

2.8

Lösungsfindung

263

Teilprobleme

(Eigenschaft)

Form des Tischblattes

Material

Kantenform

Stützkonzept

Lösungen

(Ausprägungen der Teilprobleme)

Holz

Metall

Stein

Glas

Abb. 2.90 Beispiel Morphologischer Kasten

Jede Beurteilung und Entscheidung ist subjektiv. Entscheidungen werden unbewusst

oder bewusst getroffen. Im Buch „Fühlen, Denken, Handeln“ kommt Gerhard Roth zu

folgenden Schlüssen: „Alle unsere bewussten Entscheidungen, auch die nach langem

Nachdenken und Abwägen getroffenen, werden vorbereitet und getroffen durch unbe-

wusste Vorgänge. Emotionen haben bei Entscheidungsprozessen das erste und das letzte

Wort. Es gibt keine rein rationalen Entscheidungen. Vernunft und Verstand sind nur Ratge-

ber für Entscheidungen. Das Gehirn entscheidet immer nur aufgrund einer zu erwartenden

Belohnungssituation. Auch das Vermeiden oder Vermindern von unangenehmen Zustän-

den ist eine Belohnung. Belohnungserwartungen werden durch Gefühle vermittelt. Das

emotionale Erfahrungssystem lässt Wünsche, Absichten und Pläne überhaupt erst entste-

hen. Und es entscheidet, ob das, was geplant ist, wirklich jetzt und so und nicht anders

ausgeführt werden soll. Dies garantiert, dass wir alle Handlungen stets im Lichte der ver-

gangenen Erfahrung tun. Allerdings schließt dies Fehlentscheidungen nicht aus. Verstand

und Vernunft sind notwendig für das Bewerten komplexer, detailreicher Situationen, das

Abrufen und Anwenden von Expertenwissen, das Abschätzen mittel- und langfristiger

Konsequenzen – insbesondere im sozialen Bereich – und das Abwägen von Handlungs-

alternativen. Verstand und Vernunft entscheiden nichts. Dies tut das emotionale System.“

(Roth 2001, S. 445)

264

Methodik

Nutzwertanalyse Hauskauf

Ziele

Alternative A

Alternative B

Alternative C

Muss-Ziele

Info

Ja/Nein

Info

Ja/Nein

Info

Ja/Nein

Kosten/Mt. <2500 €

mind. 3 Schlafzimmer

1900 €

2400 €

2800 €

nein

Wunsch-Ziele

Info

GxW

Info

GxW

Info

GxW

Zentrale Lage

Schulnähe

Komfort

Hausstil

10' Bus

20' Bus

4½ Zi.

Altbau

100

5' zu Fuss

15' zu Fuss

6½ Zi.

Betonbau

225

160

405

Gesamtnutzen = Summe aller GxW

300

Zielerreichungsgrad

30%

850

85%

Abb. 2.91 Beispiel Nutzwertanalyse

Für das Projektmanagement bedeutet dies, dass Entscheide, die andere Verhaltenswei-

sen verlangen, emotional so vorbereitet werden müssen, dass die Entscheidungsträger und

die von einer Veränderung Betroffenen spüren, dass die Erneuerung für sie Vorteile bringt.

Entscheide müssen emotional nachvollzogen werden können. Entscheidungen können mit

systematischen Methoden nachvollziehbar gemacht werden. Die weitaus gebräuchlichste

Methode für die Entscheidungsprozesse in der Praxis ist die Nutzwertanalyse. Die Metho-

de sieht objektiv aus, kumuliert jedoch subjektive Beurteilungen.

In der Nutzwertanalyse wird ein Punktwert für alle in Frage kommenden Lösungsal-

ternativen ermittelt, wie in Abb. 2.91 gezeigt. Dieser Punktwert ist ein Indikator für die

Erfüllung der Ziele eines Projekts. Die Nutzwertanalyse wird in fünf Schritten durchge-

führt:

Ziele bestimmen und gewichten (schon vor der Lösungssuche!)

Werte für die Varianten vergeben

Gewichte mit den vergebenen Werten multiplizieren

Gewichtete Gesamtsumme ermitteln

Sensitivität des Ergebnisses (durch Verschiebung der Gewichte) analysieren

2.8

Lösungsfindung

265

Wie sollen Lösungen bewertet werden?

Für die Auswahl der deﬁnitiven Lösung werden die Varianten verglichen und bewertet

(evaluiert). Als Bewertungskriterien sind die Detailziele gemäß Zielformulierung heranzu-

ziehen, eventuell ergänzt mit davon abgeleiteten Hilfskriterien (z. B. Kostenkomponenten

für ein Kostenziel; allerdings gehören ﬁnanzielle Aspekte in die auf die Nutzwertanaly-

se aufbauende Kosten-Wirksamkeits-Analyse). Lösungen bewerten heißt, sie bezüglich

Erfüllung der Detailziele zu beurteilen. Vorab sind alle Lösungsvarianten auf Erfüllung

der Ausscheidekriterien zu überprüfen. Wenn eine Variante ein Ausscheidekriterium nicht

erfüllt, ist sie unbrauchbar. Lösungsvarianten müssen so weit ins Detail ausgearbeitet wer-

den (meistens in der Konzeptphase), dass sie mit genügender Sicherheit bezüglich der

Erfüllung von Ausscheidekriterien überprüft werden können.

Die brauchbaren Varianten sind im nächsten Schritt bezüglich Erfüllung der Optimie-

rungskriterien zu beurteilen. Dabei bekommt der Zielerfüllungsgrad einer Variante für

jedes Optimierungskriterium einen Punktwert. Für diese Bewertung ist es günstig, einen

sinnvollen und vertrauten Maßstab (z. B. 1–10) zu wählen. Es kann von Bedeutung sein,

ob ein Neutralwert (z. B. drei in der Skala 1-2-3-4-5) möglich ist oder nicht. Entsprechend

ist eine ungerade oder gerade Skala zu wählen. Das Gewicht multipliziert mit dem Wert

ergibt den Teilnutzen (oder Teilnutzwert) einer Lösungsvariante bezüglich eines Beurtei-

lungskriteriums. In der Realität fällt es häuﬁg schwer, einem Kriterium überhaupt einen

Wert (in Form einer Zahl) zuzuweisen. Beispiel: „Wie gut ist die Benutzerfreundlichkeit

einer ICT-Anwendung?“ Hier muss die Gruppe eine Hilfestellung in Form eines Ras-

ters oder einer Tabelle erarbeiten, welche eine objektivere Benotung der nicht messbaren

Kriterien erlaubt. Wird die Nutzwertanalyse im Team durchgeführt, so sind idealerweise

die Wertungen im Konsens zu ermitteln. Wenn die Bewertung der Varianten relativ nahe

beieinanderliegende Gesamtnutzwerte ergibt, so stellt sich die Frage der Zufälligkeit der

Resultate und damit der Rangfolge. In solchen Fällen hilft eine Sensitivitätsanalyse. Das

heißt, Gewichte oder Werte werden leicht abgeändert und ihr Einﬂuss auf die Rangfolge

beobachtet. Diese Sensitivitätsanalyse ermittelt, wie stabil oder empﬁndlich ein Bewer-

tungsergebnis auf veränderte Annahmen reagiert. Immer wenn Zweifel über das Resultat

bzw. die Rangfolge auftreten, sind sofort die Vollständigkeit der Optimierungskriterien

und deren Gewichte zu überprüfen. In der Praxis werden ganze Zielklassen wie psycholo-

gische oder politische Ziele als Bewertungskriterien oft weggelassen, was zu gravierenden

Fehlern in der Beurteilung führt. Abb. 2.91 zeigt ein Beispiel einer Nutzerwertanalyse.

Der Gesamtnutzen einer Variante muss unabhängig von ﬁnanziellen Zielen ermittelt

werden (in Punkten oder in %). Mit der Kosten-Wirksamkeitsanalyse wird anschließend

berechnet, wie viel ein Punkt kostet, bzw. wie viele Punkte es pro Geldeinheit bei jeder

Variante gibt, wie in Tab. 2.55 gezeigt.

Zusätzlich zu den Zielen können weitere Kriterien hinzugezogen werden, z. B. die Re-

sultate einer Risikoanalyse. Sind die Risiken bei den Varianten stark unterschiedlich, so

sind solche Einﬂussfaktoren ebenfalls in die Beurteilung einzubeziehen.

266

Methodik

Tab. 2.55 Beispiel Kosten-Wirksamkeits-Analyse

Beispiel: Kosten-Wirksamkeits-Analyse für den Kauf eines Hauses

Nutzwertanalyse mit einem

Maximum von 1000 Punkten

Variante A zu 1900 C bei 300

Punkten Zielerreichung

Variante B zu 2400 C bei 850

Punkten Zielerreichung

Kosten/Punkt in C

6,33

2,82

Punkte/Geldeinheit

0,16

0,35

Wer soll Lösungen bewerten?

Die hier dargestellte Bewertungsmethode ist die allgemein übliche für irgendeine Eva-

luation. Es ist aber auch klar, dass eine solche Benotung subjektiv ist und daher nicht

von einer Person allein vorgenommen werden darf (es sei denn durch den Auftraggeber,

der den Schlussentscheid über die deﬁnitive Lösung hat). Eine Lösungsbewertung (Eva-

luation) im Projekt ist nichts anderes als eine Zielerreichungskontrolle und damit eine

Hauptaufgabe des Projektleiters als Verantwortlicher für die Zielerreichung.

Es obliegt also dem Projektleiter, für diese Aufgabe ein geeignetes Bewertungsteam

(„Review-Team“ oder „Jury“) zusammenzustellen und mit diesem zusammen die Bewer-

tung durchzuführen. Da sich dieses Bewertungsteam primär aus Vertretern der späteren

Benutzer und wichtiger Betroffener zusammensetzen sollte, ist es dafür besonders geeig-

net. Die Teammitglieder sind mit dem Problem vertraut, haben früher vielleicht die Ziele

und Gewichte gesetzt und wurden meistens nicht direkt in der Lösungssuche involviert.

Damit ist dieses Team eher noch neutral. In Fällen, wo ein Projektausschuss oder eine

Begleitgruppe besteht, ist es sinnvoll, diese Gremien für die Bewertung zuzuziehen.

Um das Bewertungsteam zu befähigen, qualiﬁziert eine Bewertung abzugeben, müssen

ihm die Vor- und Nachteile der Lösungsvarianten bezüglich jedes Kriteriums erläutert

werden. Dazu können ad hoc Fachkräfte zugezogen werden, welche die Lösungsvarianten

kennen. Sie können diese erläutern und Fragen des Teams beantworten.

2.8.2.2

Alternativen zur Nutzwertanalyse

Ausscheidekriterien, „Muss-Ziele“ oder Rahmenbedingungen sind zwingend einzuhal-

ten, selbst wenn es mehr kostet oder länger dauert. Dazu gehören vor allem Gesetze,

Sicherheitsvorschriften, eventuell Normen. Die präzise Deﬁnition eines Ausscheidekri-

teriums bedingt, dass seine Erreichung spätestens bei Abschluss des Projektes auch ein-

deutig beurteilt werden kann. Beim Vergleich verschiedener Lösungsvarianten werden

Ausscheidekriterien nur mit „ja“ oder „nein“ beantwortet. Fehlen die klaren Kriterien für

ein „ja“, entstehen Diskussionen über die Zielerreichung und die Durchführbarkeit des

Projektes. Wenn die Forderung der eindeutigen Beurteilung nicht erfüllbar ist, kann ein

Ziel formal kein Ausscheidekriterium sein.

Optimierungskriterien sind Ziele ohne Ausscheidungs-Charakter. Sie werden oft

als „Wunsch-Ziele“ bezeichnet. Da diese starke Wünsche sein können und außerdem

oft noch gegenläuﬁg sind, wie z. B. Kostenziele einerseits und Kosten verursachende

Leistungs- und Qualitätsziele andererseits, müssen Optimierungskriterien immer mit

2.8

Lösungsfindung

267

Tab. 2.56 Rangreihenverfahren

Kriterium

Nennungen

Gewicht

(%)

Gerundet

(%)

(A)

–

(B)

–

(C)

Tab. 2.57 Präferenzmatrixverfahren

Kriterium

Nennungen

Gewicht

(%)

Gerundet

(%)

–

einer zusätzlichen Angabe, der Gewichtung versehen werden. Die Gewichtung ist am ein-

fachsten verständlich, wenn sie in % ausgedrückt wird. Das Gewicht kann unterschiedlich

ermittelt werden:

Rangreihenverfahren (Tab. 2.56) vergleichen und relativieren alle Gewichtungen un-

tereinander (jedes mit jedem). Im Paarvergleich wird unter allen Optimierungskriterien

festgestellt, welches Kriterium jeweils wichtiger ist als das andere.

Präferenzmatrixverfahren (Tab. 2.57) bestimmen das jeweils wichtigere Kriterium

in der Tabelle. Dabei fallen die eingeklammerten Vergleiche A-A usw. weg. Die Punkte

werden schließlich in % umgerechnet.

Anstelle des zeitlich etwas aufwändigen Paarvergleichs können den Optimierungskri-

terien Punkte geben werden: z. B.: 4 = äußerst wichtig, 3 = sehr wichtig, 2 = wichtig,

1 = nett zu haben.

2.8.2.3

Übersicht über die Vorgehensschritte der Lösungsbewertung

Die Vorgehensschritte in der Lösungsbewertung sind die folgenden:

Zielformulierung mit Gewichten muss vorliegen

Mindestens zwei Lösungsvarianten, die alle Ausscheidekriterien erfüllen, für eine Be-

wertung genügend ins Detail ausarbeiten

Ein Bewertungsteam (Review-Team, Ausschuss, Jury) und bei Bedarf Fachspezialisten

für die Varianten-Erläuterung organisieren

Wenn möglich ein Bewertungsschema zusammen mit dem Bewertungsteam erarbeiten

und das Benotungssystem (die Skala) festlegen

Die Erfüllung aller Ausscheidekriterien jeder Variante durch das Team beurteilen las-

sen

Die Varianten anhand der vorgegebenen Optimierungskriterien individuell bewerten

Den Nutzwert und die Kosten-Wirksamkeit jeder Variante berechnen und die Rangfol-

ge festlegen

268

Methodik

In Zweifelsfällen die Vollständigkeit der Kriterien (Detailziele) und der Gewichte über-

prüfen, eventuell mit Sensitivitätsanalyse oder Risikoanalyse

Die vorgeschlagene beste Variante durch den Auftraggeber bestätigen lassen

Der Projektleiter muss sich, selbst wenn er als Generalist nicht bei der Lösungserarbei-

tung beteiligt war, auf alle Fälle in diesen Evaluationsprozess einklinken und ihn korrekt

durchführen. Er kann sich damit auch am besten mit dem Lösungsvorschlag identiﬁzie-

ren. Dieses transparente Vorgehen ist das bestmögliche für die Bewertung in Fällen, wo

die Lösungsvarianten relativ ähnlich sind und die Rangfolge nicht auf Anhieb ersichtlich

ist. Es führt zudem zu einer besseren Akzeptanz der Lösung, sowohl bei den Betroffenen

wie beim Auftraggeber.

2.9

Beschaffung

In vielen Projekten müssen Güter oder Dienstleistungen eingekauft werden, um die ge-

forderte Leistung erbringen zu können. Abhängig von der agilen oder klassischen Vorge-

hensweise im Projekt muss das Beschaffungsvorgehen gewählt und angepasst werden.

Für die Durchführung einer Beschaffung sind je nach Organisation Richtlinien oder

Gesetze zu berücksichtigen. Solche Vorgaben geben den Beschaffungsprozess vor und

sind von den Projekten verbindlich einzuhalten. Öffentliche Auftraggeber müssen ge-

setzliche Vorschriften einhalten und sind auch in der agilen Vorgehensweise gezwungen,

das klassische Beschaffungsvorgehen einzuhalten, außer die gesetzlichen Möglichkei-

ten lassen ein Dialogverfahren zu. In solchen Fällen werden oft Ressourcen von einem

Unternehmen klassisch eingekauft. Die Zusammenarbeit mit den Mitarbeitern des Unter-

nehmens im Projekt erfolgt dann agil.

2.9.1

Beschaffungsvorgehen in der agilen Vorgehensweise

Idealerweise wurden vor dem Start der Beschaffung bereits ein Produktkonzept (Abschn.

2.4.2) und ein initiales Product Backlog (Abschn. 2.4.3) ausgearbeitet. Die Rolle des

Product Owners (Abschn. 2.3.9.4) sollte zur Sicherstellung des Know-hows nicht extern

eingekauft werden.

Bei der Beschaffung in der agilen Vorgehensweise geht es darum, die am besten geeig-

neten Ressourcen einzukaufen. Dafür empﬁehlt es sich, zusammen mit mehreren Anbie-

tern ein kleines Testprojekt zu realisieren. Der Prozess sieht wie folgt aus:

Beschaffungsbedarf klären

Geeignete Anbieter auswählen

Pilotprojekt umsetzen

Vertrag verhandeln und Beschaffung abschließen

2.9

Beschaffung

269

Dieses Vorgehen wird auch Dialogverfahren genannt. Für den Einkauf von Gütern und

anderen Dienstleistungen kann in der agilen Vorgehensweise gleich vorgegangen werden,

oder der Einkauf wird wie in der klassischen Vorgehensweise abgewickelt.

2.9.1.1

Beschaffungsbedarf klären

Zuerst wird geklärt und deﬁniert, was genau beschafft werden soll: Personal, Dienstleis-

tung usw. Sollen einzelne Personen für das Team oder ein ganzes Team beschafft werden.

Zusätzlich ist zu überlegen, wie viele Personen wie lange benötigt werden.

2.9.1.2

Geeignete Anbieter auswählen

In einem ersten Schritt sind potentielle Anbieter zu identiﬁzieren.

Basierend auf dem Produktkonzept, dem initialen Product Backlog und dem Beschaf-

fungsbedarf wird in einem zweiten Schritt ein Fragenkatalog an die Anbieter ausgearbei-

tet. Mögliche Themen für diesen Fragekatalog sind:

Vorstellung des Unternehmens

Mitarbeiterstruktur: sind Ressourcen mit den notwendigen Skills verfügbar?

Wie würde ein mögliches Projektteam seitens des Anbieters aussehen?

Erfahrungen und Referenzen mit ähnlichen Projekten

Beurteilung der Komplexität des zu realisierenden Projektes

Vorschlag für ein Projektvorgehen: Projektorganisation, Rollen und Verantwortlichkei-

ten, Risikomanagement, Qualitätssicherung

Den identiﬁzierten Anbietern werden nun der Fragebogen, das Produktkonzept und das

initiale Product Backlog zugestellt.

Im nächsten Schritt präsentieren die Anbieter dem Evaluationsteam ihre Lösungsvor-

schläge und Antworten zu den Fragen. Zum Abschluss werden zwei oder drei Anbieter

für die Umsetzung eines Pilotprojektes ausgewählt.

2.9.1.3

Umsetzung eines Pilotprojektes

Während der Umsetzung eines Pilotprojektes gilt es nun, den besten der zwei bis drei

eingeladenen Anbieter auszuwählen. Während der Präsentation werden sich die Unter-

nehmen von ihrer besten Seite zeigen. Erst mit der konkreten Zusammenarbeit ﬁndet man

das Mindset, die Arbeitsweise, die Art der Kommunikation, die Chemie zwischen den be-

teiligten Personen usw. heraus. Daher lässt man nun jeden Anbieter mit dem eigenen Team

ein kleines Pilotprojekt während beispielsweise einem Sprint von zwei Wochen umsetzen.

Nach zwei Wochen kann neben der persönlichen Beziehung und Chemie zwischen den in-

volvierten Personen auch das konkrete Ergebnis beurteilt werden. Zudem ist es möglich,

die Efﬁzienz der Mitarbeiter des Anbieters zu beurteilen.

Basierend auf den gewonnenen Erkenntnissen und weiteren Entscheidungskriterien

(z. B. Preis) wird der deﬁnitive Anbieter ausgewählt.

270

Methodik

2.9.1.4

Vertrag verhandeln und Beschaffung abschließen

Mit dem ausgewählten Anbieter wird ein Vertrag ausgehandelt. Die nicht berücksichtigten

Unternehmen werden informiert.

2.9.2

Beschaffungsvorgehen in der klassischen Vorgehensweise

Der Prozess für eine umfassende Beschaffung unterteilt sich in folgende Schritte:

Beschaffungsbedarf klären

Beschaffungsplan erstellen

Ausschreibungsunterlagen erstellen

Ausschreibung und Evaluation durchführen

Vertrag verhandeln und Beschaffung abschließen

Für kleinere Beschaffungen können einzelne Schritte übersprungen werden. Die Dauer

einer Beschaffung ist stark abhängig von der Komplexität des Beschaffungsgegenstandes

und der geltenden Vorgaben. Einfache Güter und Dienstleistungen können innerhalb von

Tagen oder Wochen eingekauft werden. Bei komplexen Beschaffungen kann der ganze

Prozess mehrere Monate dauern. Die Dauer für die Durchführung von Beschaffungen ist

in der Projektplanung (Abschn. 2.3.11.2 bzw. Abschn. 2.4.7) zu berücksichtigen.

2.9.2.1

Beschaffungsbedarf klären

In einem ersten Schritt muss geklärt und deﬁniert werden, was genau beschafft werden

soll. Der Beschaffungsbedarf muss bezüglich der zu beschaffenden Ressource (Personal,

Werkzeuge, Materialien, Services, Teillieferungen usw.) und der zu beschaffenden Menge

geklärt werden. Der Beschaffungsbedarf lässt sich am einfachsten in der Form eines Las-

tenheftes (Abschn. 2.3.3) formulieren. Die Erarbeitung eines Lastenheftes kann je nach

Komplexität mehrere Wochen oder Monate in Anspruch nehmen. Wenn genaue Vorstel-

lungen des Beschaffungsgegenstandes vorhanden sind, kann die Beschreibung auch in

Form eines Pﬂichtenheftes erfolgen (Abschn. 2.4.5).

Bei der Beschaffung von Gütern oder Dienstleistungen spielen auch strategische Über-

legungen eine Rolle. In einem Projekt zur internen Prozessoptimierung oder in einem

Produktentwicklungsprojekt ist sehr genau zu überlegen, was die eigene Kernkompetenz

und der kritische Erfolgsfaktor oder die USP (Unique Selling Proposition) ist. Kompeten-

zen im Bereich der kritischen Erfolgsfaktoren oder der USP sind selber aufzubauen und

nicht extern zu beschaffen.

2.9.2.2

Beschaffungsplan erstellen

Im Beschaffungsplan werden das Vorgehen für die Beschaffung und wichtige Eckpunkte

für die Beschaffung festgehalten. Der Beschaffungsplan wird oft auch als Beschaffungs-

oder Ausschreibungskonzept bezeichnet. Das Vorgehen wird mit den Vorgaben der

2.9

Beschaffung

271

Stammorganisation (Beschaffungsrichtlinien) und der gesetzlichen Grundlagen abge-

stimmt. Der Beschaffungsplan muss mit in der Projektplanung berücksichtigt werden und

kann je nach Dauer der Beschaffung die Projektplanung stark beeinﬂussen.

Der Beschaffungsplan gibt Antworten auf folgende Fragestellungen:

Was ist der Beschaffungsgegenstand, was soll in welcher Menge und Qualität beschafft

werden?

Was sind die erwarteten Kosten für den Beschaffungsgegenstand?

Wie hoch ist das geschätzte ﬁnanzielle Beschaffungsvolumen?

Gibt es bereits strategische Partnerschaften oder Verträge mit Lieferanten, die berück-

sichtigt werden müssen oder können?

Wie sieht der Markt aus, welche und wie viele potentielle Lieferanten gibt es?

Welches Ausschreibungsverfahren/welche Beschaffungsmethode soll angewendet wer-

den?

Aus welchen Teilen bestehen die Ausschreibungsunterlagen?

Wie sieht die Detailplanung bezüglich Terminen und Durchlaufzeiten für die Durch-

führung der Ausschreibung aus?

Welche Ressourcen werden für die Durchführung der Ausschreibung benötigt? Wer ist

für welche Tätigkeiten verantwortlich?

Tab. 2.58 zeigt die Beschaffungsmethoden und deren Unterschiede.

Bei der Wahl des Ausschreibungsverfahrens ist zwischen privaten Unternehmen und

öffentlichen Auftraggebern zu unterscheiden. Bei öffentlichen Auftraggebern gibt es deﬁ-

nierte Schwellenwerte (ﬁnanzielles Beschaffungsvolumen), welche das Ausschreibungs-

verfahren vorgeben. Für öffentliche Auftraggeber wird zwischen den Verfahren gemäß

Tab. 2.59 unterschieden.

Private Unternehmen sind in der Beschaffung frei und an keine Schwellenwerte gebun-

den. Das heißt, Sie können in der Beschaffung direkt potentielle Lieferanten anschreiben

oder eine Beschaffung auch auf einer geeigneten Plattform publizieren und ausschreiben.

Tab. 2.58 Beschaffungsmethoden

RFI: Request for Information

Beim RFI wird überprüft, ob der skizzierte Bedarf durch poten-

tielle Anbieter erbracht werden kann. Unverbindliche Preis- und

Leistungsangaben werden eingeholt. RFI eignet sich für Markt-

abklärungen.

RFQ: Request for Quotation

Abfragen von unverbindlichen Preisen zu einem deﬁnier-

ten Beschaffungsgegenstand. Dazu sollte ein ausgearbeitetes

Lasten- oder Pﬂichtenheft oder eine Leistungsbeschreibung vor-

liegen.

RFP: Request for Proposal

RFP ist die Ausschreibung im engeren Sinn. Verbindliche Ange-

bote und Vertragsspeziﬁkationen werden vor der Ausarbeitung

des Vertragswerkes eingeholt.

272

Methodik

Tab. 2.59 Ausschreibungsverfahren

Einladungsverfahren/

beschränkte Ausschrei-

bung

Eine deﬁnierte Anzahl von Unternehmen wird angeschrieben und

gebeten, einen RFI, RFQ oder RFP abzugeben.

Offenes Verfahren

Die Ausschreibungsunterlagen werden auf einer Ausschreibungs-

plattform öffentlich publiziert. Alle interessierten und geeigneten

Unternehmen können ein Angebot einreichen.

Selektives Verfahren/

nicht offenes Verfahren

In einem ersten Schritt werden Präqualiﬁkationsunterlagen auf einer

Ausschreibungsplattform öffentlich publiziert. Alle interessierten und

geeigneten Unternehmen können sich für eine Teilnahme an der Aus-

schreibung anmelden. Die ausschreibende Stelle wird mindestens drei

geeignete Unternehmen auswählen. Im zweiten Schritt erfolgt mit den

präqualiﬁzierten Unternehmen die Durchführung der Ausschreibung

(RFP) unter Ausschluss der Öffentlichkeit. Dieses Verfahren eignet

sich für hoch komplexe Beschaffungen (z. B. neues Rollmaterial für

eine Bahngesellschaft).

Freihändige Vergabe/

Verhandlungsverfahren

Ein öffentlicher Auftraggeber kann Aufträge direkt vergeben. Dieses

Verfahren wird nur für kleine Auftragsvolumen oder in Spezialfällen

angewendet. Es ﬁndet keine Ausschreibung statt, der Auftrag wird

direkt vergeben, und die Vergabe muss begründet werden.

2.9.2.3

Ausschreibungsunterlagen erstellen

Wenn der Beschaffungsgegenstand und das Vorgehen geklärt sind, können die Ausschrei-

bungsunterlagen erstellt werden. Das Erstellen der Ausschreibungsunterlagen ist ein auf-

wändiger Prozess und dauert in der Regel länger als die Durchführung der effektiven

Ausschreibung. Die Ausschreibungsunterlagen setzen sich aus folgenden Dokumenten

zusammen:

Hauptdokument (wird oft als Lastenheft, Ausschreibungsunterlagen oder in der Praxis

häuﬁg fälschlicherweise Pﬂichtenheft bezeichnet)

Eignungskriterien

Zuschlagskriterien

Beschreibung des Beschaffungsgegenstandes

Vertragsentwurf

Lastenheft, Ausschreibungsunterlagen

Das Hauptdokument ist das übergeordnete Manteldokument der Ausschreibungsunter-

lagen. Es dient den potentiellen Anbietern als Orientierung und regelt den Ablauf des

Beschaffungsverfahrens. Typische Inhalte sind:

Beschreibung des Auftraggebers

Zielsetzung der Beschaffung

Grundlagen der Beschaffung

Fristen und Termine

2.9

Beschaffung

273

Beschreibung der Ist-Situation

Grobe Beschreibung und Anforderungen an den Beschaffungsgegenstand

Vertragliche Regelungen (Vertragsentwurf)

Beurteilung und Bewertung der Angebote: Erläuterung der Eignungs- und Zuschlags-

kriterien, zu verwendende Formulare, Angabe, wie Angebote beurteilt werden

Ausgestattung des Angebots: Aufbau und Gliederung des Angebots

Administratives: Kontaktstelle, Umgang mit Fragen, Regelung zu Teilangeboten und

Varianten, Einbezug von Subunternehmern, Zulassung von Bietergemeinschaften, Ort

der Leistungserbringung, Sprache des Angebots

Einzelne Inhalte können sehr umfassend sein und als Beilage zum Hauptdokument

angefügt werden.

Eignungskriterien

Die Eignungskriterien beschreiben die Kriterien, welche ein Anbieter mindestens erfüllen

muss. Es handelt sich hierbei oft um Anforderungen an den Anbieter bezüglich Leis-

tungsfähigkeit, Erfahrung oder Referenzen. Es können auch Mindestanforderungen an

den Beschaffungsgegenstand formuliert werden. Eignungskriterien müssen durch das an-

bietende Unternehmen erfüllt werden. Unternehmen, welche die Eignungskriterien nicht

erfüllen, werden vom Beschaffungsverfahren ausgeschlossen.

Zuschlagskriterien

Mit den Zuschlagskriterien wird das beste Angebot ermittelt. Die Zuschlagskriterien die-

nen zur Beurteilung der Qualität und des Preises der angebotenen Leistung. Es ist sinnvoll,

die Zuschlagskriterien, deren Gewichtung und wie die Erfüllung der Zuschlagskriterien

beurteilt wird, bereits mit der Publikation der Ausschreibungsunterlagen bekannt zu ge-

ben. Diese Angaben sind für potentielle Lieferanten wichtig, um beurteilen zu können, ob

sie ein Angebot abgeben wollen oder nicht.

Beschreibung des Beschaffungsgegenstandes

Um gute und aussagekräftige Angebote zu erhalten, empﬁehlt es sich, den Beschaffungs-

gegenstand in einer guten Qualität, d. h. präzise und vollständig zu beschreiben. Dabei

sollen die Kriterien analog der SMART-Kriterien angewendet werden (Abschn. 2.3.2.4)

Vertragsentwurf

Um schwierige Verhandlungen vor der Vergabe zu vermeiden, ist es sinnvoll, den Aus-

schreibungsunterlagen einen Vertragsentwurf beizulegen.

2.9.2.4

Ausschreibung und Evaluation durchführen

Nachdem die Ausschreibungsunterlagen fertiggestellt und freigegeben sind, werden diese

an die potentiellen Lieferanten versendet oder auf einer Ausschreibungsplattform pu-

bliziert. Den potentiellen Anbietern wird eine Frist für die Einreichung der Angebote

274

Methodik

gegeben. Während dieser Frist haben die Anbieter oft Fragen, welche beantwortet wer-

den müssen.

Nach Eingang der Angebote werden diese beurteilt und evaluiert. In einem ersten

Schritt wird die Erfüllung der Eignungskriterien geprüft. Unternehmen, welche die Eig-

nungskriterien nicht erfüllen, werden vom Beschaffungsverfahren ausgeschlossen. Die

Ermittlung des besten Angebotes erfolgt mit den Zuschlagskriterien. Je nach Situation

können die Anbieter zu einer Angebotspräsentation eingeladen werden. Jedes Angebot

wird anhand der Zuschlagskriterien beurteilt. Die Resultate der Beurteilung werden in ei-

ner Nutzwertanalyse zum Beschaffungsgegenstand (Abschn. 2.8.2.1) zusammengefasst.

Daraus lässt sich dann einfach das beste Angebot ableiten.

2.9.2.5

Vertrag verhandeln und Beschaffung abschließen

Oft gibt es zum besten Angebot noch offene Fragen, welche mit dem Anbieter geklärt und

bereinigt werden müssen. Diese Klärung der Fragen erfolgt zusammen mit der Verhand-

lung des Vertrages. Bei der Verhandlung sind die Grundsätze der Verhandlungsführung

(Abschn. 4.3) zu berücksichtigen.

Mit dem Abschluss des Vertrages ist die Beschaffung abgeschlossen. Alle anbietenden

Unternehmen werden über die Vergabe informiert. Wenn notwendig, wird die Vergabe auf

der Ausschreibungsplattform bekannt gemacht.

Literatur

Kolb, C. (26. November 2014). Der agile Projektleiter – Bindeglied zwischen Scrum und klassi-

schem Umfeld. ProjektMagazin, 17

Kunz, Christian (2007). Strategisches Multiprojektmanagement (Konzeption, Methoden und Struk-

turen). Gabler Edition Wissenschaft

Roth, Gerhard (2001). Fühlen, Denken, Handeln: Wie das Gehirn unser Verhalten steuert. Frankfurt

am Main: Suhrkamp.

Schwaber, Kenn und Sutherland, Jeff (2017). Der Scrum Guide. http://scrumguide.org

Mensch

Im Projektmanagement ist der Mensch Akteur. Mehrere Akteure arbeiten in Projekten de-

ﬁnitionsgemäß zusammen und kommunizieren miteinander. Deshalb ist es wichtig, den

Menschen besser zu verstehen, um ihm die entsprechenden Rahmenbedingungen zu bie-

ten, dass er in der Projektarbeit und im Zusammenwirken sein ganzes Potenzial entfalten

und die erwarteten Leistungen erbringen kann.

Im Taylorismus sollte der Mensch wie eine Maschine funktionieren. Doch wir wissen,

dass der Mensch weder ein rationales Wesen ist noch nach kausalen Wirkungszusammen-

hängen erklärt werden kann. Vielmehr ist der Mensch ein hochkomplexes Wesen, dessen

Identität stark durch seine Umwelt geformt wird und der ein Hirn hat, welches zeitlebens

seine Form verändert (Neuroplastizität).

Projektarbeit ist immer wieder auch eine persönliche Grenzerfahrung, da innerhalb

begrenzter Ressourcen Innovation geschaffen werden muss. Dieses Kapitel erläutert die

Grundzüge des modernen Menschenbildes, die Themen Stress und Veränderung, Flow,

sowie Motivation und Sinn. Dies ist die Grundlage für das Selbstmanagement, welches

die selbstgesteuerte und eigenverantwortliche Entwicklung des persönlichen Lebens zum

Ziel hat. Abgeschlossen wird dieses Kapitel mit Aspekten der eigenverantwortlichen Wei-

terentwicklung und den Grundlagen der zwischenmenschlichen Kommunikation.

Der Mensch ist immer derselbe, ob er im klassischen oder agilen Projektmanagement

unterwegs ist. Die Ausführungen in diesem Kapitel beziehen sich auf beide Ansätze.

3.1

Kompetenzmodell

Entsprechend der Aufteilung dieses Buches sind die Anforderungen und Aufgaben in ver-

schiedene Kompetenzen aufgegliedert, wie Abb. 3.1 zeigt. Die Methodenkompetenzen

werden im 2. Kapitel behandelt. Im 3. Kapitel werden die Selbstkompetenz sowie die

persönliche Kommunikation beschrieben. Kap. 4 beschreibt die Anforderungen an die

Sozial-, Team- und Führungs- sowie die Verhandlungskompetenz. Je nach Rolle im Pro-

275

J. Kuster et al., Handbuch Projektmanagement, https://doi.org/10.1007/978-3-662-57878-0_3

276

Mensch

Methodenkompetenz

– Projektabwicklung

– Planung

– Organisation

– Controlling

– Information &

Kommunikation

– Stakeholder Management

– Risikomanagement

Selbstkompetenz

– Menschen- & Weltbild

– Wahrnehmung &

Bewusstsein

– Motivation & Sinn

– Selbstmanagement

– Umgang mit Stress

– Persönliche Veränderung &

Weiterentwicklung

– Kultur und Werte

Sozialkompetenz

– Macht & Autorität

– Persönliche Kommunikation

– Interdisziplinäre & multi-

kulturelle Zusammenarbeit

– Konﬂiktmanagement & Krisen

– Umgang mit Widerstand

Verhandlungs-

kompetenz

– Verhandlungsführung

– Verhandlungs-

zyklus & Strategie

Fachkompetenz

– Im Rahmen

der Projektrolle

Team- und

Führungskompetenz

– Position & Rollen

– Delegation & MbO

– Dynamik in Teams

– Führungsstile & Selbststeuerung

– Sitzungen leiten & moderieren

– Veränderung in Organisationen

Abb. 3.1 Kompetenzmodell

jekt ergeben sich unterschiedlich gewichtete Kompetenzproﬁle für die einzelnen Stellen-

inhaber. Für Auftraggeber und Projektleiter werden diese in Abschn. 4.1.13.2 dargestellt,

für Product Owner und Scrum Master in Abschn. 4.1.12.2. Die Fachkompetenz ergibt

sich durch die jeweilige Aufgabenstellung des Projektinhaltes und ist nicht Inhalt dieses

Buches.

3.2

Bedingungen für gute Leistung

Kompetenzen alleine sind leider noch nicht Garant für eine erfolgreiche Projektarbeit.

Nach Sprenger (2014, S. 183 ff.) hängt gute Team-Leistung von drei Einﬂussfaktoren ab

(Abb. 3.2):

Leistungsbereitschaft (Wollen): Jeder Mensch muss eine Aufgabe leisten wollen. Da-

für gibt er sich eine innere Bewilligung.

Leistungsfähigkeit (Können): Auch wenn jemand noch so motiviert ist, reicht das

nicht für eine gute Leistung. Die persönlichen Fähigkeiten müssen den Anforderungen

der Aufgabe einigermaßen entsprechen.

3.2

Bedingungen für gute Leistung

277

Leistungs-

möglichkeit

Soziales Dürfen

• Regeln und (unausge-

sprochene) Normen

• Organisationskultur

Situatives Ermöglichen

• Aufgaben, Verantwortung

und Kompetenzen

• Situative Gegeben-

heiten: Ressourcen,

Zeitbudget, Hilfsmittel

Leistungsbereitschaft

Persönliches Dürfen

und Wollen

• Innere Bewilligung

• Werte, Moral, Selbstwert

• Über- oder Unterschätzung

Leistungsfähigkeit

Individuelles Können

• Individuelle Fähigkeiten

und Fertigkeiten

• Über- oder Unterforderung

Verhalten

Leistung

Abb. 3.2 Bedingungen guter Leistung

Leistungsmöglichkeit (Dürfen): Einerseits muss die Organisation einer Person zuge-

stehen, eine speziﬁsche Leistung zu erbringen (Soziales Dürfen). Andererseits müssen

die entsprechenden Produktionsmittel und Kapazitäten zur Verfügung stehen.

Mit optimal entwickelten Kompetenzen wird die Leistungsfähigkeit gestärkt. Die Leis-

tungsbereitschaft und die Leistungsmöglichkeit sind damit noch nicht beeinﬂusst. Oft wird

auch versucht, durch zusätzliche Motivationsfaktoren Projektteams zu höheren Leistungen

anzuspornen. Die Motivation beeinﬂusst primär die Leistungsbereitschaft. Die persönliche

Leistungsfähigkeit wie etwa methodische oder fachliche Kompetenzen werden dadurch

nicht gesteigert. Auch die Leistungsmöglichkeit bleibt durch die Motivation vorerst die-

selbe.

Beispiel

Ein junger Projektleiter, der motiviert (leistungsbereit) und gut ausgebildet (leistungs-

fähig) ist, hat erst Erfolg, wenn die Organisationskultur sein Wirken unterstützt (Leis-

tungsmöglichkeit). Wird er von den „Altgedienten“ in der Firma zu seiner Funktion

ermächtigt und respektiert (Soziales Dürfen) und in das informelle Netzwerk aufge-

nommen, entfaltet sich seine Handlungsfähigkeit. Zudem braucht er die zeitlichen Res-

sourcen, um die Aufgabe erfolgreich zu bewältigen.

278

Mensch

Die Gestaltung der Leistungsmöglichkeit wird wohl am häuﬁgsten unterschätzt: Es

gibt immer wieder operativ sehr gut geleitete Projekte, die nur aus dem Grund schei-

tern, dass sie keine Leistungsmöglichkeit haben. Die Leistungsmöglichkeit ist initial von

den Führungsverantwortlichen der Stammorganisation bereitzustellen. Zudem ist auch die

Projektorganisation selber immer wieder damit herausgefordert, optimale Rahmenbedin-

gungen für die Zusammenarbeit im Team zu schaffen. Dies betont die Wichtigkeit der

Arbeit am System (Abschn. 1.5.2).

Alle Mitglieder von Projektteams sollen immer wieder die eigene Leistung in Bezug

setzen zur Leistungsmöglichkeit. Unter sehr schwierigen Rahmenbedingungen lässt sich

ein Projekt kaum mehr oder weniger auf Kurs halten. Sind die Rahmenbedingungen aber

optimal, dürfen und müssen positive Projektresultate erwartet werden. Somit ist es mit

der Beurteilung der persönlichen Leistung wie mit der Abhängigkeit von Licht und Farbe:

Farbe ist immer abhängig vom Licht; je nach Licht erscheint die Farbe anders. Die persön-

liche Leistung (Bereitschaft und Fähigkeit) ist immer abhängig von der Möglichkeit: Mit

der gleichen Leistung kann bei optimalen Verhältnissen sehr viel mehr erreicht werden,

als wenn die Rahmenbedingungen schwierig sind.

3.3

Phänomen Mensch

3.3.1

Wer sind wir?

Wer sind wir als Mensch? Was bildet unsere Identität? Sind wir die logische Konsequenz

unserer Erbanlage (Nature), oder sind wir vor allem geprägt durch unsere Umwelt (Nur-

ture)?

Die Persönlichkeit eines Menschen formt sich aus mehrschichtigen Wechselwirkungen

zwischen Erbanlage und Umwelt heraus (Abb. 3.3). Die Erbanlagen des Kindes sind ein

Ergebnis aus den Erbanlagen der Eltern. Die Eltern gestalten die direkte Umwelt des Kin-

des. Die Familie wiederum wird geprägt durch den direkten Lebensraum von Gesellschaft

und Wirtschaft. Dieser Lebensraum beeinﬂusst auch die Schule und Gemeinschaften, wel-

che zur direkten Umwelt des Kindes gehören.

Die Phase der Sozialisation, also das Hineinwachsen des Kindes in die Gesellschaft,

ist für jeden Menschen sehr prägend, denn in dieser Zeit ist auch die Hirnentwicklung am

intensivsten. Wesentlich für den Kinderarzt Remo Largo ist, dass der Entwicklungsimpuls

immer selber vom Kind kommt: „Das Kind ist kein passives Wesen, das durch die Umwelt

geformt wird. Es will auch nicht beliebige Erfahrungen machen, sondern solche, die es für

seine individuelle Entwicklung benötigt.“ (Largo 2017, S. 127)

3.3

Phänomen Mensch

279

Schule

Gemeinschaften

Peers

Gesellschaft

Wirtschaft

Eltern

Erbanlage

Kind

Erbanlage

Familie

Umwelt

Kind

Abb. 3.3 Zusammenwirken von Anlage und Umwelt in der Kindheit. (Largo 2017, S. 125)

3.3.2

Wunderwerk Hirn

Neuroplastizität: Das Hirn verändert seine Form

Unser Hirn besteht aus bis zu 100 Mrd. Nervenzellen (Neuronen). Jedes einzelne Neuron

ist wiederum mit 1000–5000 anderen Neuronen durch Synapsen verbunden. Das Hirn

funktioniert nur als Team: Ein Neuron selber kann für sich nicht viel ausrichten. Nur

wenn es sich mit Tausenden oder Millionen anderer Nervenzellen verbindet, gewinnt es

an Einﬂuss (Esch 2014, S. 68). Ein Durchbruch in der Hirnforschung war die Erkenntnis,

dass das Hirn seine Form verändert. Die Neuroplastizität lässt darauf schließen, dass

das Hirn seine Struktur nicht nur aufgrund der genetischen Marker entwickelt, sondern

auch aufgrund der Erfahrungen, die ein Mensch im Laufe seines Lebens macht. Wenn der

Mensch etwas lernt, sei das in Bezug auf sein Fühlen, Denken oder Handeln, entwickeln

sich neuronale Netzwerke in seinem Hirn. Je mehr ein speziﬁsches neuronales Netzwerk

mit Erfolg benutzt wird, desto stärker wird dieses auch ausgebaut. Es entwickelt sich –

bildlich gesprochen – vom Trampelpfad zur Autobahn.

Neurons wire together if they ﬁre together.

Use it or lose it.

280

Mensch

Nach diesem Bild nimmt das Gehirn des Menschen am liebsten die Autobahn. Vom

Menschen wird gesagt, er sei ein „Gewohnheitstier“. Er liebt die Netzwerke an Denk-,

Fühl- und Verhaltensmustern, die er möglicherweise schon in der Kindheit entwickelt hat.

Diese Gewohnheiten vermitteln Routine, Sicherheit und Efﬁzienz.

Beispiel

Ein Projektleiter, der schon viele Projekte nach dem klassischen Ansatz abgewickelt

hat, ist sehr efﬁzient in der Projektplanung und in der Projektabwicklung. Wenn nun

sein Arbeitgeber entscheidet, zukünftig die Projekte nach dem agilen Ansatz abzuwi-

ckeln, sind die Routinen und Strategien des Projektleiters plötzlich nicht mehr hilfreich.

Er ist damit herausgefordert, dass er sich mit der agilen Methodik intensiv auseinan-

dersetzt und darin auch seine neue Rolle als Product Owner oder Scrum Master ﬁndet.

Leben heißt Veränderung (Abschn. 3.5.3). Menschen sind immer wieder mit der Er-

fahrung konfrontiert, dass die bestehenden Autobahnen des Fühlens, Denkens und Han-

delns nicht mehr zielführend sind. Die Autobahn kann nur verlassen werden, indem man

sich Stück für Stück ein neues Verhaltensmuster antrainiert. Das ist natürlich sehr an-

spruchsvoll. Dabei entwickeln sich im Gehirn neue neuronale Netzwerke, was viel mehr

Energie erfordert, als die bestehenden Gewohnheitsmuster abzurufen, den Autopiloten

laufen zu lassen. Die gute Nachricht ist aber, dass das menschliche Gehirn dank der Neu-

roplastizität neue Autobahnen anlegen kann, kurz gesagt, lernfähig ist.

Auch die Umkehr davon ereilt uns Menschen immer wieder: Neuronale Netzwerke,

die längere Zeit nicht benötigt werden, bauen sich wieder ab. Das Gehirn hat einen sehr

efﬁzienten Energiespar-Modus und funktioniert nach dem Motto: „Use it or lose it.“

Beispiel

Für den oben beschriebenen Projektleiter wird es nicht reichen, einfach ein Seminar

zum agilen Projektmanagement zu besuchen und dann die Vorstellung zu haben, dass

er wieder mit der gleichen Souveränität und Efﬁzienz die Rolle des PO bekleiden kann.

Was er sich in jahrelanger Praxis als klassischer Projektmanager angeeignet hat, muss

er nun z. T. loslassen können. Er setzt sich intensiv mit dem agilen Ansatz und dessen

kritischen Erfolgsfaktoren wie der Selbststeuerung, dem Entwickeln der Produktvision

oder dem Aufbau des Product Backlog auseinander. Dabei bildet sein Gehirn diese

neuen Kompetenzen als neue neuronale Netzwerke ab. Das bedeutet, dass sein agiles

PM-Seminar nur Früchte tragen wird, wenn er die neuen Ansätze immer wieder neu

praktiziert. Sollte er irgendwann später wieder in ein klassisches Projekt einberufen

werden, könnte er sich damit schwertun, die klassischen Planungstools zu bedienen

oder ein Lastenheft zu entwickeln.

Wo ist die Zentrale im Hirn?

Das Hirn ist als Teil des zentralen Nervensystems des Menschen dessen oberstes Steue-

rungsorgan. Lange Zeit war die Frage nicht beantwortet, wo denn die „Steuerung der

3.3

Phänomen Mensch

281

Steuerung“ ansässig sei, welches also innerhalb des Hirns selber wiederum die höchste

Instanz sei für das Fühlen, Denken und Handeln des Menschen. Mittlerweile konnte die-

se Funktion dem Frontallappen der Großhirnrinde zugeordnet werden, dem präfrontalen

Kortex. Er bildet die Regierung oder das Exekutivkomitee im Gehirn und ist charakteri-

sierend für die Spezies Mensch grundsätzlich und für die jeweilige Person im Speziellen

(Esch 2014, S. 86). Alle Erfahrungen, die ein Mensch im Laufe seines Lebens macht, wer-

den im diesem Frontallappen gespeichert. Immer wiederkehrende Erfahrungen werden

dabei verdichtet. Daraus resultiert schließlich die innere Haltung eines Menschen, seine

Einstellung. Da diese Erfahrungen aufgrund der Neuroplastizität Teil der Hirnstruktur des

jeweiligen Menschen geworden sind, lassen sich die neuen Haltungen und Einstellungen

nur mit großem Aufwand wieder verändern.

Das Besondere am Frontallappen ist, dass es sich um ein gekoppeltes Netzwerk mit ei-

nem kognitiven und einem emotionalen Anteil handelt. Jede Erfahrung wird also mit der

dazugehörenden Emotion gespeichert. Haltungen können zwar vom Menschen rational

begründet werden, sie sind aber immer auch emotional verankert und damit fühlbar. Aus

diesem Grund kann persönliche wie auch organisationale Veränderung, die nur rational

begründet wird, nicht erfolgreich sein. Nachhaltige Veränderung ist immer begleitet von

einem sicherheitsstiftenden Raum, in welchem Menschen und Organisationen neue Erfah-

rungen machen können (Ballreich und Hüther 2009). Mehr dazu in Konﬂiktbewältigung

(Abschn. 4.4.10).

Vom Wissen zum Können

Auch die Reﬂexion, die Vernunft und die allgemeinen Intelligenz- und Verstandesfunk-

tionen und damit die Steuerung unseres Handelns werden dem präfrontalen Kortex zu-

geordnet. Das Wissen, welches der Mensch sich angeeignet hat, sei dies in Mathematik,

Sprache oder im Expertenwissen seiner Berufstätigkeit, dient ihm als Werkzeugkoffer und

ist in der Großhirnrinde gespeichert.

Abb. 3.4 stellt den Zusammenhang zwischen Daten, Informationen, Wissen und Kön-

nen dar: Daten haben wir im digitalen Zeitalter in Hülle und Fülle. Daten, welche unter-

einander zusammenhängen, werden zu Information. Aus Informationen, welche für eine

Person Sinn machen, wird speziﬁsches Wissen. Mit Wissen können wir Probleme lösen.

Das Wissen wird zu Können, wenn es gelingt, neue, bisher unbekannte Probleme zu lö-

sen. Damit wird wiederum neues Wissen generiert. Um das Wissen umzusetzen, ist die

Grenze zwischen Wissen und Können immer wieder zu überschreiten. Dies führt zurück

zum Thema „Trampelpfad und Autobahn“. Das Können, das neue Lösungen generieren

kann, legt einen neuen Trampelpfad an, der durch Wiederholung zu einer neuen Autobahn

ausgebaut wird. Übung macht den Meister. Weitere Ausführungen zu den Strategien der

persönlichen Veränderung ﬁnden sich in Abschn. 3.5.4.

282

Mensch

Daten

Informationen

Wissen

Können

Abb. 3.4 Wissen und Können. (Pﬂäging 2015, S. 36)

3.3.3

Grundbedürfnisse bestimmen unser Leben

Mittlerweile vertritt die Mainstream-Psychologie die Auffassung, dass das Verhalten des

Menschen zielorientiert ist und dass sich diese Ziele aus den persönlichen Grundbe-

dürfnissen des Menschen ableiten (Bamberger 2005, S. 283). Welches aber diese Grund-

bedürfnisse des Menschen sind, darüber bestehen unterschiedliche Ansätze.

„Die Grundbedürfnisse, so wie sie ausgebildet sind, prägen die Individualität eines

Menschen und haben großen Einﬂuss auf sein Leben“ (Largo 2017, S. 204). Die Erb-

anlage schafft dazu die organischen Voraussetzungen und legt auch deren Ausprägung

fest. Bis zu welchem Grad das Kind dann aber seine individuellen Grundbedürfnisse be-

friedigen kann, hängt von seiner Umwelt ab. So kann ein Kind, je nachdem, wie seine

Grundbedürfnisse angelegt sind und welche Erfahrungen es macht, Leistung und soziale

Anerkennung als erstrebenswerte Ziele verinnerlichen oder diesen – gerade im Gegen-

teil – wenig Beachtung schenken. Die Einstellung, die es dadurch gewonnen hat, kann

später im Erwachsenenleben dazu führen, dass es entweder eine sehr leistungskritische

oder leistungsorientierte Haltung einnehmen wird. Remo Largo unterscheidet zwischen

den nachfolgend beschriebenen, in Abb. 3.5 aufgeführten sechs Grundbedürfnissen.

3.3

Phänomen Mensch

283

Existenzielle

Sicherheit

Körperliche

Integrität

Geborgenheit

Selbstentfaltung

Leistung

Anerkennung

Sozialer Status

Abb. 3.5 Grundbedürfnisse des Menschen. (Largo 2017, S. 183 ff.)

Körperliche Integrität

Die Befriedigung der elementaren körperlichen Bedürfnisse bildet eine Grundlage dafür,

dass auch die anderen Grundbedürfnisse befriedigt werden können. Dazu gehört die aus-

reichende Ernährung, der erholsame Schlaf, nicht übermäßig frieren oder schwitzen zu

müssen, das Ausleben der Sexualität und auch die physische Leistungsfähigkeit. Ein we-

sentlicher Bestandteil dieses Grundbedürfnisses ist die Gesundheit des Menschen. Von

den Heilsritualen über die Schamanen zur modernen Medizin: Der Mensch hat für seinen

Gesundheitszustand immer sehr viel Energie aufgewendet.

Geborgenheit und Zuwendung

Das Verlangen nach Geborgenheit und Zuwendung ist ein uraltes psychisches Grundbe-

dürfnis des Menschen. Ohne die Bindungsbereitschaft der Eltern würden Kinder nicht

überleben – sind sie doch auf deren Zuwendung angewiesen. Die Liebe ist für die meisten

Menschen wohl die stärkste Emotion. Durch sie stillt der Mensch sein Verlangen danach,

bedingungslos angenommen zu sein.

Kinder sind enorm stark auf die Geborgenheit und Zuwendung angewiesen. Im Er-

wachsenenalter lässt das etwas nach, aber das Bedürfnis nach Nähe und Zuwendung

vertrauter Menschen bleibt bestehen.

284

Mensch

Anerkennung und sozialer Status

Der Mensch kann – wie viele Tierarten auch – nur in der Gemeinschaft überleben. In

dieser Gemeinschaft entwickelten unsere Vorfahren ein Bedürfnis nach sozialer Aner-

kennung und einer gesicherten sozialen Stellung. Dieses Grundbedürfnis kann in ganz

unterschiedlichen Gemeinschaften befriedigt werden. Für die Einen steht dabei die Fami-

lie im Vordergrund, für die Anderen die Berufs- oder Freiwilligenarbeit etc. Es ist auch

nicht so, dass man nur als Projektleiter, CEO, Vereinspräsident oder Familienoberhaupt

zufrieden sein kann: „Die meisten Menschen sind dann zufrieden, wenn sie die soziale

Stellung einnehmen können, die ihnen entspricht, und wenn sie die soziale Anerkennung

bekommen, die sie aufgrund ihrer Leistung erwarten dürfen“ (Largo 2017, S. 193).

Was aber für alle Menschen gilt: Alle Menschen wollen in ihrer sozialen Stellung

beachtet werden, sei diese auch noch so bescheiden. Jede Form von Ausgrenzung be-

einträchtigt das Wohlbeﬁnden.

Selbstentfaltung

Der Mensch will die in ihm angelegten Fähigkeiten so gut wie möglich entfalten können.

Schon Kinder haben ein ausgeprägtes Verlangen danach, Fähigkeiten auszubilden und

sich Fertigkeiten und Wissen anzueignen.

Kinder wie auch Erwachsene neigen jedoch immer wieder dazu, sich zu überfordern

oder Idealen nachzueifern, die sie nicht erfüllen können. „Jedes Kind ist mit einem in-

dividuellen Entwicklungspotenzial bezüglich Ausprägung und Reifungsgeschwindigkeit

seiner Eigenschaften und Fähigkeiten geboren. Je nach Lebensbedingungen, unter denen

es aufwächst, kann es sein Potenzial unterschiedlich gut ausschöpfen. Das Kind kann sich

aber selbst unter optimalen Lebensbedingungen nicht über sein Entwicklungspotenzial hi-

naus entwickeln. Es gibt keine Förderung über das individuelle Begabungspotenzial eines

Menschen hinaus“ (Largo 2017, S. 114).

Demnach ist für das Wohlbeﬁnden und das Selbstwertgefühl des Menschen nicht der

Erfolg selber entscheidend, sondern ob es gelingt, die individuellen Begabungen zu ent-

falten.

Streben nach Leistung

In der Leistung will der Mensch mit seinen Fähigkeiten und Fertigkeiten – welche er sich

über die Selbstentfaltung angeeignet hat – speziﬁsche Ergebnisse erzielen.

Der Mensch will nicht nur leisten, um dadurch seinen Lebensunterhalt zu verdienen

oder soziale Anerkennung zu erreichen. Der Mensch will auch leisten, weil er sich damit

in einer Selbstwirksamkeit erfahren und auch sein Selbstwertgefühl stimulieren kann.

Wie wichtig die erbrachten Leistungen für Kinder und auch Erwachsene sind, zeigt

sich in unseren Emotionen: Gelingt uns ein Erfolg, empﬁnden wir Freude und Euphorie.

Scheitern wir in einem wichtigen Vorhaben, sind wir traurig und betrübt. Wer permanent

unterfordert ist, fühlt sich gelangweilt und frustriert. Wer dauerhaft überfordert ist und

nie das Gefühl haben kann, etwas erreicht zu haben, fühlt sich desillusioniert oder sogar

erschöpft.

3.3

Phänomen Mensch

285

Auch bei der Leistung geht es nicht darum, dass jede Person auf den Mount Everest

klettern, einen Marathon rennen oder um die Welt radeln muss. Es geht darum, dass der

Mensch die Leistungen erbringen kann, die seinen Fähigkeiten oder Fertigkeiten entspre-

chen.

Existenzielle Sicherheit

Erlebt der Mensch mangelnde existenzielle Sicherheit oder verliert er diese sogar total,

löst das bei ihm übermächtige Ängste aus. Menschen, die von Armut, Krieg oder Vertrei-

bung betroffen sind, sind zutiefst emotional verunsichert und psychisch traumatisiert.

Der Mensch teilt mit vielen Tieren seinen Drang zur Vorsorge und zur Schaffung von

Sicherheit: Das Eichhörnchen legt Vorräte an, der Maulwurf zieht sich in sein Höhlensys-

tem zurück. Der Mensch lebte zuerst in Höhlen, dann in Steinhütten und Höfen. Heute

bilden Städte, Vorsorgesysteme oder Versicherungen der modernen Welt die Grundlagen,

um die existenzielle Sicherheit zu erhöhen.

Dabei interpretieren die Menschen existenzielle Sicherheit unterschiedlich: Die einen

wollen ihren Lebensunterhalt bezahlen können, die anderen streben nach Reichtum und

Macht. Manchen ist die Altersvorsorge enorm wichtig, und für gewisse ist das völlig ne-

bensächlich.

Jeder Mensch ist einzigartig. Je mehr der Mensch in seinem Leben Wahl- und

Entscheidungsfreiheiten hat, desto mehr wird er versuchen, sein Leben so zu

gestalten, dass er diese Freiheiten so gut wie möglich ausleben kann. Die eine

Person strebt mehr nach Status und Anerkennung, für andere ist die Geborgen-

heit oder die existenzielle Sicherheit sehr viel wichtiger. Ein gut oder schlecht

gibt es bei diesen Ausprägungen nicht. Aber diese Ausprägungen der Bedürf-

nisse haben Einfluss auf die Persönlichkeitsmerkmale, die z. B. über Persönlich-

keitstypologien wie Belbin oder MBTI (Abschn. 3.10.2) erfasst werden können.

Je besser der Mensch sich selber kennt, desto mehr kann er auch ein Umfeld su-

chen, welches ihm am besten entspricht,so wie auch der Kaktus die Trockenheit

braucht und das Schilfrohr die Nässe. Wer einen starken Drang nach Anerken-

nung und sozialem Status hat, wird sich als Mitglied eines agilen Teams mit kol-

legialer Führung kaum wohlfühlen. Und wem Geborgenheit und Zuwendung

wichtig ist,der wirdin der Rolle desProduct Ownersnicht glücklich werden.Bes-

ser wäre in diesem Fall, wenn die beiden Personen die Rollen tauschen würden,

vorausgesetzt natürlich, sie bringen dazu auch die entsprechenden fachlichen

Kompetenzen mit.

3.3.4

Spezielle Bedürfnisse der Generation Y

Jede Generation hat auch ihre speziellen Charakteristika der Grundbedürfnisse. Diese

werden unter anderem von den gesellschaftlichen Rahmenbedingungen bzw. vom Ent-

286

Mensch

wicklungsstand der Gesellschaft, von der herrschenden Kultur, von weltbewegenden Er-

eignissen usw. geprägt.

Für die Arbeitswelt sind besonders die Kenntnisse der Bedürfnisse und Erwartungen

der jungen Generation, die auch Millennials oder Generation Y genannt wird, interessant.

Im Folgenden sind einige Charakteristika, Bedürfnisse und Erwartungen jüngerer Men-

schen an die Arbeitswelt genannt:

Sie sind in der Regel gut ausgebildet und investieren auch in ihre Weiterbildung.

Sie suchen in der Arbeit Sinn: sie muss interessant und vor allem sinnvoll sein.

Sie streben nach Autonomie, übernehmen dann aber auch Verantwortung.

Beruﬂiche Weiterentwicklung ist ihnen wichtig, jedoch eher in Richtung Projekt- oder

Expertenlaufbahn als in der Führung von Mitarbeitern.

Sie lassen sich nicht ans Unternehmen binden.

Sie sind engagiert, optimieren sich aber auch selber. So ist ihnen die Life-Balance

sehr wichtig. Konkret heißt das: Arbeitszeit-Souveränität, Auﬂösung der Trennung von

Beruf und Privatleben, auch Zeit für die Familie, usw.

Sie sind kritisch gegenüber Hierarchien, arbeiten jedoch gerne in Teams.

In der VUKA-Welt von Volatilität, Unsicherheit, Komplexität und Ambiguität sind sie

zu ständiger Anpassung gezwungen; hier können sie besser improvisieren als die Ge-

nerationen vor ihnen.

Natürlich treffen diese Eigenschaften nicht für alle zu. Bei gewissen Menschen ist auch

das Gegenteil feststellbar, sei es ein übertriebener Wunsch nach Sicherheit, Anpassung

oder Rückzug ins Private. Aber es ist ein Trend. Gerade das moderne Projektmanage-

ment sollte in der Lage sein, für diese Bedürfnisse die passenden Rahmenbedingungen

zu bieten: Teamarbeit, Gestaltungsfreiheit, Entscheidungskompetenzen, Selbstorganisati-

on usw. Nur so, und nicht durch möglichst viel Geld und Statussymbole, kann es die guten

Mitarbeiter gewinnen, auf die es heute so angewiesen ist. In unseren (noch) weitgehend

hierarchisch geführten Unternehmen ist das eine große Herausforderung. Doch die Er-

fahrung zeigt, dass bei entsprechenden Rahmenbedingungen ein großes Potenzial genutzt

werden kann.

In der Projektarbeit geht es vor allem darum, die unterschiedlichen Fähigkeiten

der verschiedenen Generationen im Team optimal zu kombinieren. Dazu muss

ein gegenseitiges Verständnis zwischen Jüngeren und Älteren entwickelt wer-

den. Das bedeutet auch, dass ein guter Umgang mit Differenzen immer wieder

neu gefunden werden muss. Das Thema steht im Konfliktmanagement im Mit-

telpunkt (Abschn. 4.4.1).

3.3

Phänomen Mensch

287

Somatosensorischer Bereich

Tasten

Olfaktorischer Bereich

Riechen

Auditorischer Bereich

Hören

Visueller Bereich

Sehen

Gustatorischer Bereich

Schmecken

Abb. 3.6 Wo die Sinne verarbeitet werden

3.3.5

Wahrnehmung des Menschen

Ein Bild sagt mehr als tausend Worte

Durch diese Volksweisheit wurde schon vor langer Zeit auf ein Phänomen der menschli-

chen Wahrnehmung hingewiesen, welches nachfolgend erörtert werden soll. Der Mensch

(resp. sein Gehirn) erhält durch seine Sinne Informationen über seine Umwelt. Aristoteles

deﬁnierte die fünf bekannten Sinne von Sehen, Hören, Riechen, Schmecken sowie Tas-

ten. Die moderne Forschung fügt noch weitere Sinne hinzu wie die Wahrnehmung des

Gleichgewichts (Vestibulärer Sinn), die Fähigkeit, die Position einzelner Körperteile im

Vergleich zu anderen einzuschätzen (Propriozeptionssinn) oder den viszeralen Sinn mit

der Fähigkeit, Signale aus dem Innenleben unseres Körpers wie Hunger und Durst wahr-

zunehmen (Amrein 2015, S. 63).

Das Sehen und das Tasten sind die beiden dominanten Sinne des Menschen. Das Tasten

geht über unsere Haut, die das größte Organ des Menschen ist. Die nach vorne ausge-

richteten Augen des Menschen verdeutlichen die Wichtigkeit des Sehens. Für das Hören,

Riechen und Schmecken stehen im Hirn weit weniger Kapazitäten zur Verfügung, wie in

Abb. 3.6 ersichtlich ist (Donzé und Pﬁster 2015).

288

Mensch

Selektive Wahrnehmung

Das, was wir wahrnehmen („als wahr nehmen“), kann niemals objektiv sein. Zuerst ein-

mal haben unsere Sinne eine „mechanische“ Begrenzung: Wir Menschen können nur

das Licht bestimmter Wellenlängen sehen und nur Töne bestimmter Frequenzen hören.

Wir können auch nicht alles riechen, schmecken und ertasten. Vielmehr handelt es sich

bei unserer Wahrnehmung um einen hochkomplexen Verarbeitungsprozess, welcher im-

mer rein subjektiv und selektiv zu bewerten ist: „Das aus all diesen Sinneseindrücken

zusammengesetzte Bild ist freilich kein wahres Abbild der tatsächlichen Beschaffenheit

der äußeren Welt, sondern lediglich das Bild, das wir uns mit all unseren Beschränkungen

von dieser Welt machen können.“ Der Mensch hat die einzigartige Fähigkeit, seine Wahr-

nehmung zu bewerten. Er kann sich auf speziﬁsche Wahrnehmungen aus der äußeren wie

auch inneren Welt fokussieren und diese in den Mittelpunkt setzen oder auch als völlig

unbedeutend im Hintergrund lassen (Hüther 2001, S. 103 ff.). Diese Wahrnehmung ist bei

allen Menschen unterschiedlich, basiert sie doch darauf, wie intensiv speziﬁsche neurona-

le Wahrnehmungsnetzwerke ausgebildet worden sind. Je nachdem, wie stark wir unsere

Sinne auf gewisse Phänomene „schärfen“, sind wir dann sehr sensibilisiert auf speziﬁsche

Wahrnehmungen.

In der interdisziplinären Projektarbeit werden uns diese gegensätzlich „geschärften“

Wahrnehmungen immer wieder bewusst: Ein technischer Experte, sei es ein Informatiker,

ein Maschinenbauer oder ein Elektroingenieur, hat im Bereich seiner Fachkompetenz ei-

ne hochdifferenzierte Wahrnehmung in Bezug auf die technische Problemstellung. Für

Störungen auf der Beziehungsebene, Unterlassungen im Bereich des Stakeholder-Ma-

nagements oder auch die Wichtigkeit von gut vorbereiteten und moderierten Sitzungen

können diese Personen wesentlich geringer sensibilisiert sein. Das ist auch kein Wunder,

haben sie doch Jahrzehnte der Aus- und Weiterbildung in ihre Fachdomäne investiert und

sich gerade aufgrund dieser Kompetenzen ihre beruﬂiche Karriere aufgebaut. Ein Pro-

duct Owner hingegen darf sich gar nicht in technischen Problemen verlieren. Einerseits

hat er eine andere Funktion im Team und andererseits wird er gar nicht die technischen

Kompetenzen haben, dies zu tun.

Wenn davon ausgegangen wird, dass die Menschen unterschiedliche Wahrneh-

mungen und damit unterschiedliche Realitäten haben, so liegt es auf der Hand,

sie „an einen Tisch“ zu bringen, um eine gemeinsame Realität entstehen zu las-

sen. Deshalb sind gemeinsame Bearbeitungen oder Absprachen so wichtig, sei-

en sie noch so kurz, dafür häufig und regelmäßig wie z. B. im Daily Standup

Meeting. Aber auch ein Perspektivenwechsel ist oft sinnvoll: sich in die Rolle des

andern, z. B. des Kunden, des Anwenders usw. zu versetzen. Was ist aus seiner

Sicht wichtig, was erwartet er vom Projekt? Da bietet sich die Stakeholder-Ana-

lyse an (Abschn. 2.3.5), die Fragetechnik (Abschn. 3.9.8) oder die Integration von

weiteren Personen in die Projektorganisation (Abschn. 2.3.9).

3.3

Phänomen Mensch

289

Zweck unserer Wahrnehmung

Unsere Sinne erfassen auch sehr viel mehr Impulse, als wir bewusst verarbeiten könnten.

Experten gehen davon aus, dass nur 5 % unserer Wahrnehmungen dem Bewusstsein wirk-

lich zugänglich gemacht werden. Die anderen 95 % der Sinneseindrücke bleiben unbe-

wusst (Stadelmann 2017). Das führt zur Frage, welcher Art die 5 % der Wahrnehmungen

sind, welche unserem Bewusstsein zugänglich gemacht werden? Weil das Überleben un-

sere wichtigste Aufgabe ist, sind alle darauf erpicht, so viel Sicherheit wie möglich um

sich herum zu schaffen. Und alles was diese Sicherheit bedroht, resp. mögliche Gefahren

mit sich bringt, ist für unsere Wahrnehmung zentral. Damit kann einfach zusammenge-

fasst werden, dass sich unsere Wahrnehmung (unbewusst) auf das fokussiert, was unsere

Sicherheit bedroht und damit einer Intervention bedarf. Die Sicherheit liegt wiederum in

der Vorhersagbarkeit. Wir lieben es nicht, überrascht zu werden. Vielmehr produziert un-

ser Hirn immer wieder neu Erwartungen an speziﬁsche Lebenssituationen. Und das, was

von diesen Erwartungen abweicht, ist in unserer Wahrnehmung zentral. Das, was nicht

abweicht, braucht keine große Aufmerksamkeit und wird vielfach auch unbewusst verar-

beitet.

Dieses Phänomen ist für das Verhalten des Menschen im Stress (Abschn. 3.5) und

in Konflikten (Abschn. 4.4) zentral: Der Stressor oder der Konflikt kann von ei-

nem Moment auf den Anderen die Wahrnehmung einzelner Projektbeteiligter

völlig vereinnahmen. Die Wahrnehmung fokussiert sich dann auf diesen – sub-

jektiv empfundenen – sicherheitsbedrohenden Aspekt. Alles andere, was gut

läuft, wird möglicherweise ausgeblendet. In dieser Situation ist es für die Pro-

jektverantwortlichen wichtig, mit den Betroffenen eine Eingrenzung machen zu

können. Sehr hilfreich sind hier die Fragetechniken (Abschn. 3.9.8) wie:

... die Beziehung zum Kollegen ist sehr angespannt. Gab es eine Zeit, in der

diese besser war? Wenn ja, was war damals anders?

... auf einer Skala von 1–10: Wie werden im Moment die Erfolgschancen für

das Projekt eingeschätzt? Was würde es brauchen, um diese Chancen um

einen Punkt zu steigern?

3.3.6

Bewusstsein und Selbstreflexion

Zwischen Reiz und Reaktion liegt ein Raum. In diesem Raum liegt unsere Macht zur Wahl

unserer Reaktion. In unserer Reaktion liegen unsere Entwicklungen und unsere Freiheit (Vik-

tor E. Frankl).

Frankl beschreibt eine ganz spezielle Gabe des Menschen: Er ist seiner selbst bewusst

und hat deshalb auch die Möglichkeit zu reﬂektieren, wie er mit der (selektiven) Wahr-

nehmung der Reize aus seiner Umwelt umgeht und wie er darauf reagiert. Dieser Raum

zwischen Reiz und Reaktion wird durch unser Bewusstsein geschaffen: Nach dem latei-

nischen Begriff „con-sciencia“ ist Bewusstsein ein begleitendes Wissen, welches um die

290

Mensch

eigene Beﬁndlichkeiten und Tätigkeiten weiß, uns aber auch die Abgrenzung erlaubt zu

unseren Mitmenschen und zur Umwelt (Rager und von Brück 2012, S. 36 ff.). Hüther

versteht unter dem Bewusstsein die Fähigkeit, die eigenen Empﬁndungen und Wahrneh-

mungen, des eigenen „In-der-Welt-Seins“ gewahr zu werden. Dank dem Bewusstsein

werden primäre Verarbeitungsprozesse, die den Leistungen des Gehirns zugrunde liegen,

ihrerseits zum Gegenstand kognitiver Prozesse gemacht (Hüther 2001, S. 115).

Beispiel

Wir können also eine Sitzung leiten und uns während dem Sprechen unserer eigenen

Beﬁndlichkeit gewahr werden: „Fühle ich mich gestresst wegen der kritischen Bemer-

kung eines Kollegen? Oder aber rede ich zu schnell, weil ich Angst habe, die Sitzung

nicht pünktlich beenden zu können?“

Durch unsere Fähigkeit, unser vordergründiges Fühlen, Denken und Handeln auf einer

höheren Meta-Ebene zu reﬂektieren, können wir wiederum unsere vordergründige Ebe-

ne beeinﬂussen. Beispielsweise langsamer sprechen oder aber die Sitzungsteilnehmenden

fragen, ob die Besprechung verlängert werden kann.

Nach Frankl liegt unsere Freiheit darin, wie wir den Raum zwischen Reiz und Reaktion

am besten nutzen. Der Mensch ist – anders als die Tiere – seinen Gefühlen und Instinkten

nicht bedingungslos ausgeliefert. Vielmehr ist er dazu befähigt, sie mit seiner Vernunft zu

kontrollieren und langfristigen Zielen unterzuordnen (Rager und von Brück 2012, S. 93).

Wenn wir also Angst haben, müssen wir nicht sofort die Flucht ergreifen. Falls uns je-

mand in einer Sitzung bloßstellt, müssen wir nicht sogleich im Affekt zurückschlagen.

Natürlich kommen in einer solchen Sitzungssituation die Gefühle hoch. Wir fühlen uns

verletzt oder auch gedemütigt. Aber trotz allem können wir dank unserem Bewusstsein

und der Vernunft bei uns bleiben und unsere Bloßstellung durch die andere Person in ihrer

verbalen und non-verbalen Kommunikation einordnen (Abschn. 3.9) und ruhig bleiben.

Dieser Prozess – der unsere Überlegungen zum Phänomen Mensch zusammenfasst – ist

vereinfacht in Abb. 3.7 dargestellt.

Nicht nur unsere Wahrnehmung ist kontextabhängig, sondern auch unser Verhalten.

Dieser Aspekt wird in Abschn. 4.1.10 behandelt.

3.3.7

Vertrauen

Vertrauen ist ein Mechanismus, der uns erlaubt, mit unserer Unsicherheit umzugehen (Chris-

toph Bosshardt).

Unser Leben ist voll von Unsicherheiten. Wenn wir beispielsweise nicht darauf vertrau-

en können, dass alle Verkehrsteilnehmer die Regeln befolgen, werden wir uns nicht mehr

ins Auto setzen. Ohne Vertrauen zum Lokführer und ins Zugleitsystem werden wir in kei-

nen Zug mehr einsteigen. Vertrauen ist Grundlage und Voraussetzung jeder qualiﬁzierten

Form der menschlichen Gemeinschaft.

3.3

Phänomen Mensch

291

Bewertung

Gefühle

Selektive

Wahrnehmung

95%

Bewusster

Prozess

Handlung Verhalten

Reiz Unbewusster

Prozess

Vernunft

Wille

Ziele

Selbstreﬂexionsfähigkeit

Kontextabhängigkeit

Abb. 3.7 Wahrnehmung und Selbstreﬂexion

Vertrauen als Erfahrung

Wie jede Fähigkeit des Menschen ist auch Vertrauen eine Mischung von genetischer Ver-

anlagung und erlerntem Verhalten. Damit das Kind lernen kann zu vertrauen, braucht es

vor allem Sicherheit. Diese Sicherheit resultiert daraus, wie feinfühlig und vorhersagbar

die Bezugspersonen auf die Bedürfnisse des Kindes eingehen (Schneider 2003). Ist die

Reaktion eines Elternteils mal liebevoll und dann wieder ein Wutausbruch, ist die Reak-

tion nicht vorhersagbar. So entsteht keine Sicherheit. Das Kind kann auch kein Vertrauen

aufbauen, weder in sich selber noch in seine Umwelt. Auch im Erwachsenenleben können

wir Vertrauen „lernen“. Dafür brauchen wir stabile Beziehungen, die Sicherheit stiften.

Synonym für Vertrauen: Nähe oder Verbundenheit

Wir vertrauen Menschen oder Organisationen, denen wir uns nahe oder verbunden fühlen.

Vertrauen ist wie Macht (Abschn. 4.1.3) immer eine Beziehungsangelegenheit. Was ist

die Grundlage von Beziehungen? Nach dem Philosophen Wilhelm Schmid sind es die ge-

meinsamen Erfahrungen. Beziehungen ohne regelmäßige gemeinsame Erfahrungen lösen

sich auf. Auch Familienbeziehungen leben davon, dass man sich immer wieder begegnet

und gemeinsame Erfahrungen macht (Schmid 2010).

292

Mensch

Vertrauen in der Berufswelt

Alle wollen heutzutage Vertrauen: Politiker von der Bevölkerung, Firmen von ihren Kon-

sumenten, Führungskräfte von ihren Mitarbeitern und Projektverantwortliche von ihren

Auftraggebern. Nur mit einer wunderbaren Ansprache oder einem schönen Werbespot ist

das aber nicht gemacht. Es braucht die Berechenbarkeit und das Gefühl der Sicherheit in

dieser Beziehung mit dem Gegenüber. Das entsteht am besten im zwischenmenschlichen

Kontakt. Deshalb ist die formale Projektkommunikation eine Grundvoraussetzung für die

Zusammenarbeit. Aber eben nur eine. Es braucht ebenso die unstrukturierten Kommu-

nikationsgefäße wie das Mittagessen und den Aperitif am Feierabend. Hier können wir

uns als Menschen außerhalb unserer Berufsrollen erfahren und damit Nähe und Sicherheit

zueinander entwickeln, was tragfähige Berufsbeziehungen ermöglicht.

Wer kein Vertrauen hat, reagiert nach außen mit einem übersteigerten Kontrollbedürf-

nis und nach innen mit Verlorenheit. Im Arbeitsleben zeigt sich das im Unvermögen,

delegieren zu können (Abschn. 4.1.8) und in hohem Perfektionismus: Vorgesetzte, die

als „Micro-Manager“ jedes Detail im Griff haben wollen.

3.3.8

Humor

Fragt der neue Mitarbeiter seinen Projektleiter: „Wie viele Menschen arbeiten eigentlich an

unserem Projekt?“ Darauf der Projektleiter; „Hm, ich schätze, so etwa die Hälfte!“ (Projekt-

magazin.de)

Dr. med. Eckart von Hirschhausen ist davon überzeugt, dass Lachen die beste Medizin

ist. Deshalb hat er sich von seiner Arzttätigkeit abgewandt, um sich dem Cabaret zu wid-

men. Er ist Buchautor und moderiert Fernsehsendungen. Hirschhausen bezeichnet den

Kampf von David gegen Goliath als Urwitz der Menschheit: „Der mächtige Riese Goliath

wird von dem körperlich unterlegenen David mit seiner Schleuder niedergestreckt. Witz

gewinnt gegen Gewalt. Und deshalb ist der kreative Geist auch so eine gute Waffe, vor

allem, wenn wir selbst der Feind sind: trübe Gedanken, üble Schmerzen oder wenn die

ganze Welt gegen uns ist“ (Hirschhausen 2016, S. 447).

Es ist eine wertvolle Kompetenz des Menschen, immer auch über sich selber lachen zu

können. Anstatt dass wir uns bei einem Missgeschick oder einem Fehler über uns selbst

ärgern und griesgrämig sind, können wir auch versuchen, über uns zu lachen. Humor er-

laubt dem Menschen, sich selber nicht so ernst zu nehmen, zu sich selber auf eine gewisse

innere Distanz zu gehen. Humor entspannt und erlaubt es einem auch, sich aus der Verbis-

senheit zu lösen und eine gewisse Lockerheit zu den aktuellen Erfahrungen zu entwickeln.

Dadurch hat Humor auch einen Einﬂuss auf unsere Resilienz (Abschn. 3.8.4) und auf un-

sere Kreativität (Abschn. 1.7).

Im Humor erfährt der Mensch, dass er ein soziales Wesen ist. So richtig herzhaft la-

chen, kann er nur in Gemeinschaft. Zusammen lachen generiert Nähe und Verbundenheit,

wodurch mehr Vertrauen entsteht.

3.4

Persönliche Kultur und Werte

293

3.4

Persönliche Kultur und Werte

3.4.1

Was ist Kultur?

Kultur bezeichnet Verhaltensnormen und gemeinsame Werte einer Gruppe von Menschen

(John Kotter).

Kultur ist die Art und Weise, wie wir Probleme lösen (Edgar Schein).

Kultur ist Teil des Gedächtnisses Ihrer Organisation. Man könnte auch sagen: Unternehmens-

kultur ist wie ein Schatten. Man kann ihn beobachten, ihn schön ﬁnden oder weniger schön.

Es gibt ihn, und man kann ihn nicht verändern – obwohl er selbst sich ständig verändert (Niels

Pﬂäging).

Die lateinische Wortwurzel von Kultur bezieht sich auf das Bewirtschaften und Kultivie-

ren des Bodens. Kultur ist alles, was der Mensch um sich herum geschaffen hat. Kultur

hat einen sichtbaren und einen unsichtbaren Teil: Sichtbar sind beispielsweise die verbale

und nonverbale Kommunikation: Sprache, Begrüßungsrituale, physische Distanz, Essen

oder Architektur.

Beim Boden kann man tiefergraben. So hat auch Kultur eine tiefere und damit viel per-

sönlichere Ebene: die Art und Weise, wie wir denken, fühlen und uns anderen Menschen

gegenüber verhalten (Dumetz 2012, S. 21). Mit dieser Betrachtungsweise sind für Kultur

noch andere Einﬂussfaktoren relevant, wie in Abb. 3.8 dargestellt.

3.4.2

Organisationskultur

Jede Gemeinschaft hat eine speziﬁsche Kultur. Dies gilt für jede Familie wie auch für

jede Organisation und für jedes Projektteam. Nach der Deﬁnition von John Kotter (2012,

S. 125) setzt sich diese zusammen aus

Speziﬁschen Verhaltensnormen: Geteilte oder vorherrschende Handlungsweisen, die

sich in einer Gruppe etabliert haben. Diese bleiben bestehen, weil Gruppenmitglieder

sich so zu verhalten pﬂegen, dass sie diese Handlungsweisen neuen Mitgliedern wei-

tervermitteln:

– Wer sich konform verhält, wird belohnt.

– Wer sich nicht konform verhält, wird bestraft.

Gemeinsamen Werten: Werte symbolisieren das, was wir für wichtig und richtig hal-

ten und an was wir uns gebunden fühlen. Unsere Werte bestimmen unsere Identität,

weshalb wir auch sehr sensibel reagieren, wenn wir uns in unseren Werten angegriffen

fühlen (Abschn. 4.4.7.8). Diese Werte haben oft noch Bestand, wenn sich die Zusam-

mensetzung der Gruppe längst geändert hat.

294

Mensch

Kultur

Physische

Distanz

Gewohnheiten

Sprache

Tradition

Essen

Religion

…

Abb. 3.8 Einﬂussfaktoren von Kultur. (Dumetz 2012, S. 22, Übersetzung des Autors)

All das ﬂießt ein in die pragmatische Deﬁnition von Edgar Schein, „Kultur ist die

Art und Weise, wie wir Probleme lösen“. Viele Aspekte der Organisation sind unsicht-

bar, vor allem für langjährige Mitglieder. Wie verläuft der Informationsﬂuss? Wie reden

wir miteinander? Wie fällen wir Entscheidungen? Wie verhalten wir uns unter Druck und

Stress? Was passiert bei Fehlern? Welche Reputation haben Projektleiter in der Organi-

sation: Karrieresprungbrett oder Abstellgleis? Diese Fragen und viele mehr sind Teil der

Organisationskultur. Gerade weil so viele Kulturaspekte tief unter dem Boden liegen, ist es

so schwierig, diese nicht nur fassbar zu machen, sondern auch zu verändern (Abschn. 4.5).

3.4.3

Sich der eigenen kulturellen Prägung bewusst werden

Wie können Sie sich Ihrer persönlichen kulturellen Prägung bewusstwerden? Einfach so

für sich selber können Sie das nicht. Sie brauchen die Begegnung mit anderen Menschen,

die Sie anders begrüßen als Sie es gewohnt sind, die andere Speisen essen, andere Wit-

ze erzählen oder andere Strategien der Problemlösung anwenden. Über die Unterschiede

kommen Sie der Sache auf die Spur.

3.5

Stress und Veränderung

295

Gewisse Dinge können wir selbst erkennen. Sehr viel bleibt unserer eigenen Wahrneh-

mung jedoch verborgen. Deshalb ist das Feedback (Abschn. 3.9.7) so wichtig. Dadurch

können wir von anderen Menschen lernen, was ihnen an uns auffällt. Natürlich hat jeder

Mensch das Recht, so zu sein wie er ist oder auch wie er sein möchte. Das verändert unsere

persönliche Kommunikation (Abschn. 3.9), unser Verhalten im Konﬂikt (Abschn. 4.4.10)

oder auch in der Verhandlungsführung (Abschn. 4.3).

3.5

Stress und Veränderung

Wir haben die Stressreaktion nicht deshalb, damit wir krank werden, sondern damit wir uns

ändern können (Gerald Hüther).

3.5.1

Hintergründe

Stress ist in unserer Gesellschaft omnipräsent. Allzu oft wird er nur negativ konnotiert.

Schon Hans Selye (1974) erkannte jedoch, dass gewisse Stressreaktionen auf den Men-

Zeit

Leistungsvermögen

hoch

klein

Anspannung

Externer Reiz

Diffuse Auf-

merksamkeit

Entspannung

Erschöpfung

Erholung

Überforderung

Abb. 3.9 Schematischer Ablauf der Stressreaktion. (Basierend auf: Drath 2014, S. 229)

296

Mensch

schen eine schädigende Wirkung und andere einen fördernden Einﬂuss haben. Er prägte

die heute noch geläuﬁgen Begriffe von Eustress für die positiven und Dysstress für die

negativen Eigenschaften. Nach Hüther (1997, S. 29 ff.) gilt diese Vorstellung heute als

veraltet. Er deﬁniert die Stressreaktion des Menschen als eine relativ unspeziﬁsche Re-

aktion des Organismus auf physische oder psychische Belastungen. Die Art der Reaktion

auf psychische Belastungen oder Herausforderungen hängt von der individuellen Bewer-

tung ab. Abb. 3.9 stellt einen schematischen Ablauf einer Stressreaktion dar. Wird ein

externer Reiz (Stressor) wahrgenommen, steigt die Anspannung des Menschen und damit

auch seine Leistungsfähigkeit. Ist der Stressor innerhalb nützlicher Zeit bewältigt, folgt

die Entspannung und damit auch die Erholung. Bleibt die Anspannung jedoch bestehen,

führt sie zuerst zu einem überfordernden Dauerstress und dann in die Erschöpfung.

3.5.2

Psychischer Stress

Bei psychischem Stress kommt unser Wahrnehmungsprozess ins Spiel. In der Projektar-

beit stehen die psychischen Stressoren im Vordergrund: Ob es sich um eine Verschiebung

eines Meilensteines handelt, ob die Qualität eines Arbeitspaketes ungenügend ist oder ob

wir mit einem enormen Leistungsdruck konfrontiert sind Diese psychischen Stressoren

sind keine manifeste, körperliche Bedrohung.

Jeder Mensch muss sich in Stresssituationen fragen: „Was steht im Mittelpunkt

meiner Wahrnehmung? Wie bewerte ich diese Situation?“ Ist jede Abwei-

chung vom Ideal gleich eine Bedrohung des Selbstwertgefühls? Kann ge-

rade in schwierigen Situationen noch unterschieden werden zwischen der

persönlichen Leistung (Wollen und Können) und der Leistungsmöglichkeit

(Abschn. 3.2)? Wie steht es um die eigene Resilienz (Abschn. 3.8.4)?

3.5.3

Leben heißt Veränderung

Die meisten leben in den Ruinen ihrer Gewohnheiten (Jean Cocteau).

Es ist ein Gesetz des Lebens, dass alles was lebt, nie so bleiben kann wie es ist. Das Leben

um uns verändert sich permanent. Auch wir selber verändern uns durch unsere täglichen

positiven und manchmal auch negativen Erfahrungen. Auf der anderen Seite versuchen

wir natürlich permanent, so viel Sicherheit und Stabilität wie möglich für uns und unser

Umfeld zu schaffen. Sicherheit hat viel mit Vorhersagbarkeit und Berechenbarkeit zu tun.

Gewohnheiten geben uns viel Sicherheit. Wir legen uns Fühl-, Denk- und Verhaltensmus-

ter zu, an denen wir uns festhalten können und die uns Orientierung geben. Das Problem

ist, dass diese Gewohnheiten oft aus der Vergangenheit stammen: Unsere Arbeitstechnik,

3.5

Stress und Veränderung

297

unser Umgang mit anderen Menschen oder unsere Reaktion in Stresssituationen. Wir ver-

suchen in all den Situationen, denen wir im täglichen Leben begegnen, zuerst mal mit

einem gewohnten Muster zu reagieren, weil uns dieses Sicherheit gibt: Das hat ja schon in

anderen Situationen funktioniert. Oft ist das durchaus eine adäquate Strategie. Es gibt aber

immer auch Lebenssituationen, in denen wir aus unseren angestammten Gewohnheiten

ausbrechen müssen. Dies wird umso schwieriger, je stärker wir an den alten Gewohnhei-

ten festhalten. Aus den Gewohnheiten auszubrechen und neue Strategien zu entwickeln

ist immer ein Weg ins Ungewisse. Dies braucht Mut und Selbstvertrauen.

3.5.4

Persönliche Bewältigungsstrategien und Dilemmata

Wenn der Mensch damit konfrontiert ist, dass er mit seinen aktuellen Strategien und Ge-

wohnheitsmustern eine neue Situation nicht bewältigen kann, stehen ihm drei Optionen

zur Verfügung:

1. Veränderung

Die äußere Situation oder das eigene Verhalten wird verändert.

2. Neubewertung

Der Mensch passt seine persönliche Bewertung an. Die Situation bleibt

bestehen, aber sie wird nicht mehr als bedrohlich oder besonders heraus-

fordernd bewertet.

3. Verdrängung

Der Mensch versucht, den Stressor zu verdrängen.

Welche die beste Strategie ist, hängt immer von der jeweiligen Herausforderung, den

Persönlichkeitsmerkmalen des Menschen und von seiner physischen und psychischen

Verfassung ab. Es gibt Situationen oder Ereignisse, die am besten verdrängt werden. In

anderen Situationen braucht es Veränderung oder eine persönliche Neubewertung.

Oft sind Projektverantwortliche mit Dilemmata konfrontiert: Ein Dilemma tritt dann

auf, wenn eine Person oder eine Organisation zwei sich widersprechende Ziele erreichen

soll.

Beispiele

Eine Firma will auf individuelle Kundenbedürfnisse eingehen, braucht aber efﬁzi-

ente Produktionsmethoden und damit Standardisierungen.

Projektleiter oder Product Owner möchten mit ihren Teams gute Beziehungen un-

terhalten, müssen aber trotzdem unpopuläre Entscheidungen fällen.

Das magische Dreieck stellt gar ein Trilemma dar: Ein anspruchsvolles Ziel (1)

muss zu einem bestimmten Zeitpunkt (2) mit einem limitierten Budget (3) erreicht

werden.

Viele Dilemmata lassen sich nur durch Veränderung der äußeren Situation oder des

eigenen Verhaltens auﬂösen. Bleibt das Dilemma bestehen, sind die Ursachen der Wider-

sprüchlichkeit zu erkennen und mit Verhandlungsführung (Abschn. 4.3) oder Ansätzen

298

Mensch

des Konﬂiktmanagements (Abschn. 4.4) oder des Risikomanagements (Abschn. 2.3.8).

immer wieder zu bereinigen.

3.5.5

Angst als Auslöser der Stressreaktion

Interessant ist, was als Auslöser der Stressreaktion erkannt worden ist: Die Angst (Hüther

1997, S. 27 ff.). Wenn immer wir etwas wahrnehmen, das nicht unseren Erwartungen ent-

spricht, werden die routinemäßig ablaufenden Prozesse im Gehirn gestört. Es breitet sich

eine Erregung aus, die alle Regionen des Körpers mit einbezieht. Eine gewisse Angst

ist also nötig, um überhaupt in diesen wichtigen Zustand der Erregung zu kommen, über

welchen wir die Energie aufbauen, um die Herausforderung zu bewältigen. Wenn wir aber

zu viel Angst haben – das hängt (auch) von unserer bewussten Bewertung ab – wird der

Stress für uns eine Bedrohung. Hüther unterscheidet hier zwischen der kontrollierbaren

und unkontrollierbaren Stressreaktion.

3.5.6

Kontrollierbare Stressreaktion

Wenn wir mit einem Stressor konfrontiert sind, wird in einer ersten Phase eine kontrol-

lierbare Stressreaktion ausgelöst. Die Nebennieren schütten das Stresshormon Adrenalin

aus. Dadurch geht der Puls hoch, die Muskulatur wird angespannt und die Blutbahnen

verengen sich. So wird Energie mobilisiert, die zu einer erhöhten Aufmerksamkeit führt

und auch eine hohe Reaktionsbereitschaft zur Folge hat. Der Mensch hat nun die Energie,

um aktiv mit dem Stressor umzugehen. Wenn der Mensch die Erfahrung macht, dass er

durch seine Stressreaktion einen Stressor erfolgreich bewältigen konnte, werden die neu-

ronalen Netzwerke in seinem Gehirn, die zur Problemlösung beigetragen haben, weiter

ausgebaut. Das wiederum wird auch das Fühlen, Denken und Handeln verändern (Hüther

1997, S. 62). Entscheidend sind die eigene positive Bewertung der Situation und auch die

Einschätzung der Bezugspersonen. Wer mit der Veränderung erfolgreich war, wird auch

zukünftig wieder die Strategien der Veränderung wählen, es zur Gewohnheit machen.

Beispiel

Einem Product Owner wird ein Team zugewiesen für ein anspruchsvolles Software-

Projekt. Das Team ist neu zusammengestellt. Einige Teammitglieder sind erst seit kur-

zem in der Firma, andere haben die Abteilung intern gewechselt. Sie sind immer noch

daran, sich mit der eingesetzten Technologie vertraut zu machen. Im Product Owner

kommt die Angst hoch, dass es trotz hoher Motivation und Commitment in seinem

Team nicht realistisch sein wird, dieses anspruchsvolle Projekt erfolgreich abzuwi-

ckeln. Aus dieser Angst kann er die Energie schöpfen, um eine der drei Strategien

der persönlichen Veränderung anzuwenden.

3.5

Stress und Veränderung

299

1. Er versucht die Situation zu verändern, indem er noch weitere Ressourcen bean-

tragt, den Scope reduziert oder eine längere Projektdauer beantragt.

2. Er nimmt eine Neubewertung vor, indem er sich bewusst der Herausforderung stellt,

mit einem unerfahrenen Team Aufbauarbeit zu leisten und Risiken einzugehen.

3. Er verdrängt seine Angst, macht einfach weiter, wie wenn nichts wäre in der Hoff-

nung, dass alles gut kommt oder dass es – wenn das Projekt scheitern würde – nicht

ihm selber angelastet wird.

3.5.7

Unkontrollierbare Stressreaktion

Wenn mit der zusätzlichen Energie der kontrollierbaren Stressreaktion der Stressor nicht

bewältigt werden kann oder wenn eine Person einer lange anhaltenden Stresssituation

ausgesetzt ist, setzt die unkontrollierbare Stressreaktion ein. Nun ist das Hirn in völliger

Unordnung: Kortisol wird ausgeschüttet, Angstschweiß und Herzrasen setzen ein, Ohn-

macht macht sich breit. Die Wahrnehmung des Menschen fokussiert sich auf die eine

wahrgenommene Bedrohung. Dies passiert vor allem dann, wenn der Mensch etwas in

Gefahr sieht, was für ihn sehr wichtig ist und wesentlich zu seiner Identität oder zu sei-

nem Selbstwertgefühl oder zu seinen stark ausgeprägten Grundbedürfnissen gehört. Für

die Einen ist das der soziale Status, für Andere die existenzielle Sicherheit. Auch jede

denkbare Veränderung in der Beziehung zu anderen Menschen kann zu einer unkontrol-

lierbaren Stressreaktion führen (Hüther 1997, S. 41).

Die fortlaufende Überﬂutung des Körpers und des Gehirns mit Kortisol führt zu ei-

nem gestörten Schlaf und auch zu einer Schwächung des Immunsystems. Damit ist die

Gesundheit des Menschen beeinträchtigt. Die positive Seite dieser Überﬂutung durch die

Stresshormone ist, dass die bestehenden Verschaltungen und damit Strategien zur Be-

kämpfung von Bedrohungen aufgeweicht werden (Hüther 1997, S. 74). Dies erlaubt dem

Menschen im positiven Fall, einen Paradigmenwechsel zu vollziehen und seine alten Stra-

tegien zur Bewältigung einer Herausforderung durch neue zu ersetzen. Im schlechteren

Fall kommt es zu einer Schädigung der körperlichen oder geistigen Integrität.

3.5.8

Bewältigung von Stressoren in der Projektarbeit

Methodik

Die Projektmanagement Methodik, wie sie in allen Aspekten in Kap. 2 dargestellt wird,

stellt keinen Selbstzweck dar. Vielmehr dient sie als Mittel zum Zweck, das Projekt so

gut wie möglich durch die Klippen der Widersprüchlichkeiten in Bezug auf Ablauf oder

Rollen, unrealistische Erwartungen oder Risiken zu führen. Wer in der Projektarbeit die

Methodik konsequent anwendet, kann sich dadurch zu einem wesentlichen Teil vor Stres-

soren schützen.

300

Mensch

Arbeitstechnik und Resilienz

In der Berufsarbeit braucht jede Person eine auf sie zugeschnittene effektive Arbeitstech-

nik und ein wirkungsvolles Zeitmanagement (Abschn. 3.8.3). Jeder Projektmitarbeiter

muss immer wieder neu klären, welche Prioritäten für ihn zentral sind und wie er am

effektivsten mit seiner Arbeitszeit umgeht. Auch die Resilienz (Abschn. 3.8.4) ist nicht

einfach gegeben. Wir alle können sie zu einem gewissen Grad aufbauen, vorausgesetzt

wir wollen das auch und setzen uns dafür ein.

Beziehungen: Freundschaft und Liebe

In herausfordernden Situationen hilft dem Menschen in jeder Situation die Verbundenheit

zu einer nahen Bezugsperson. Nur schon das Wissen, dass ein Freund oder Partner für

einen da ist und alles in seiner Macht stehende tun wird, um einem in einer herausfor-

dernden Situation beizustehen, erlaubt es dem Menschen, mit seiner Stressreaktion besser

umzugehen. Dieses Gefühl der Verbundenheit, die die Angst besiegen kann, hat einen

Namen: Die Liebe. Sie ist stärker als die Angst (Hüther 1997, S. 53 ff.). Deshalb ist es

auch so wichtig, dass der Mensch als soziales Wesen seine Beziehungen außerhalb der

Berufsarbeit pﬂegt (Abschn. 3.10.1).

Beispiel

Ein Product Owner wählt aus Gewohnheit den Weg der Verdrängung. Jetzt, wo sich

die Probleme höher auftürmen als bisher, hat er immer mehr schlaﬂose Nächte. Dies

kann zu einer unkontrollierbaren Stressreaktion führen. Er macht es aber besser: Dem

Dauerstress will er mit einer neuen Strategie entkommen. Er wird das Gespräch suchen.

Ganz wichtig ist für ihn, dass er sich in dieser Situation an eine nahe Bezugsperson

wenden kann, die Anteil an seiner Situation nimmt und ihn unterstützen kann.

3.5.9

Burnout

Lange anhaltender Stress kann zu einer Erschöpfungsdepression und zu einem Burnout

führen. Als Konsequenz unserer Leistungsgesellschaft ist Burnout ein Phänomen, wel-

ches Menschen in allen Berufsgruppen und Hierarchiestufen betrifft. Burnout kann viele

Auslöser haben: z. B. die oben beschriebenen anhaltenden Stressreaktionen oder große

Diskrepanzen zwischen Fähigkeiten und Anforderungen über längere Zeit.

Das Burnout-Syndrom entwickelt sich langsam und schleichend. Die betroffene Person

verhält sich lange Zeit unauffällig und bleibt „unentdeckt“. Es gibt große Unterschiede im

individuellen Verlauf. Doch die totale Erschöpfung tritt oft schlagartig ein. Erst im fortge-

schrittenen Stadium zeigt sich ein Burnout in den drei Formen, wie in Tab. 3.1 gezeigt.

Erschöpfungsdepressionen und das Burnout sind mittlerweile gut behandelbar durch

Medikamente und Therapien, am besten durch eine Kombination von beidem. Die Grund-

voraussetzung für die Heilung ist, dass sich die Betroffenen die Erkrankung primär selber

eingestehen. Erst in einem nächsten Schritt können sie durch professionelle Betreuung

3.5

Stress und Veränderung

301

Tab. 3.1 Formen des Burnouts

Körperliche Erschöpfung

Chronische Ermüdung, Schwächegefühl, physische Schmerzen

wie Kopf-, Rücken-, Muskelschmerzen, Gewichtsschwankungen,

Schlafstörungen, Erhöhte Anfälligkeit für Erkrankungen

Emotionale Erschöpfung

Niedergeschlagenheit, Hilﬂosigkeit, Weinen, unkontrollierte Ge-

fühlsausbrüche, Reizbarkeit, Leere, Mutlosigkeit, Vereinsamung

Geistige Erschöpfung

Negative Einstellung gegenüber sich selbst, zur Arbeit und zum

Leben, erhöhtes Minderwertigkeitsgefühl, Verlust der Selbstachtung,

zunehmende Kontaktabnahme und Kommunikationsverweigerung,

Zynismus, Suizidgedanken und Aggressivität

wieder zu einer besser ausgeglichenen Energiebilanz kommen. Die Maßnahmen dazu sind

für jede Person und Situation verschieden. Grundsätzlich wird es aber immer darum ge-

hen, den Umgang mit den eigenen Grenzen zu bearbeiten. Wer ein Burnout erleidet, hat in

irgendeiner Art seine persönlichen Ressourcen ausgebeutet. Das ist wohl der schwierigs-

te Schritt für leistungsorientierte Menschen: zu lernen, dass die persönlichen Ressourcen

beschränkt sind und sich bewusst zu machen, dass man nicht allen Ansprüchen und An-

forderungen an die eigene Person gerecht werden kann.

Den Anforderungen und Erwartungen an einen Menschen aus seinem berufli-

chen und privaten Umfeld sind keine Grenzen gesetzt: Linienvorgesetzte, Auf-

traggeber,Kunden,Lieferanten,Projekt-undLinienmitarbeiter,Arbeitskollegen,

alle weiteren Stakeholder des Projekts und dann noch das persönliche private

Umfeld.Alle diese Menschen können Ansprüche an eine einzelne Person stellen,

die diese bei weitem überfordern. Der Mensch ist in seiner Leistungsfähigkeit

begrenzt und braucht seine Erholungsräume. Im Projektmanagementliefert die

Methodik wichtige Impulse, um die Komplexität sichtbar zu machen und einen

realistischen Umgang damit zu finden. Möglichkeiten bieten die Klärung des

Scope, das Stakeholder-Management oder die Planung.

Alleine ist eine nachhaltige persönliche Veränderung, wie ein Burnout sie erfordert,

fast nicht zu leisten. Deshalb wird stark empfohlen, dass sich Betroffene durch eine Lern-

begleitung durch einen Coach unterstützen lassen. Ein Wiedereinstieg in die angestammte

Aufgabe wäre nach Paul Watzlawick eine Lösung erster Ordnung, mehr des Gleichen.

Die Gefahr besteht, wieder in die alten Muster des Denkens, Fühlens und Handelns zu-

rückzufallen. Das nächste Burnout stünde vor der Tür. Nachhaltige Lösungen brauchen

neue Herangehensweisen. Im Falle des Wiedereinstiegs in die angestammte Berufsauf-

gabe nach einem Burnout sollen die betroffene Person, deren Linienvorgesetzter und ein

Coach die Stelle mit ihren Aufgaben, Entscheidungskompetenzen und Verantwortlichkei-

ten neu beschreiben.

302

Mensch

3.6

Flow

Ein weiteres Konzept zur Beschreibung gesunder und ungesunder Belastung ist das Flow-

konzept (Csikszentmihalyi 2004).

Csikszentmihalyi’s Forschungsschwerpunkt ist die Frage, was das Leben eines Men-

schen lebenswert macht, wofür er brennen kann und was ihm die Energie gibt, um sich

für Dinge einzusetzen, die weder Reichtum noch Ruhm versprechen. Er nennt den Zu-

stand des Menschen Flow, wenn er sich selber in einer Aufgabe völlig vergessen kann

und ES – sein Werk – wie von selbst entsteht. So erleben sich Musiker in einem Flow,

wenn das Stück sich wie von selbst komponiert. Schriftsteller berichten darüber, dass sich

irgendwann die Romanﬁguren selbständig machen.

In allen Flow-Erlebnissen ist der Umstand identisch, dass in diesen Momenten das Be-

wusstsein für die eigene Identität verschwindet. Man geht in der einen, aktuellen Tätigkeit

auf und vergisst sich selber in seiner Körperwahrnehmung. Die Alltagssorgen, die sonst

im Kopf kreisen, sind weg.

In Abb. 3.10 sind die unterschiedlichen Zustände dargestellt, in denen sich der Mensch

beﬁnden kann. Das Konzept setzt die Anforderungen, die an einen Menschen gestellt wer-

Erregung

Flow

Kontrolle

Angst

Langeweile

Apathie

Sorge

Entspannung

niedrig

Fähigkeiten

hoch

Anforderungen

niedrig

hoch

Abb. 3.10 Flow-Konzept. (Csikszentmihalyi 2004)

3.6

Flow

303

den, in Relation zu dessen persönlichen Fähigkeiten. Der Referenzpunkt ist die Mitte. Von

hier aus positioniert sich jeder Mensch in jeder Aufgabe in Bezug auf seine Fähigkeiten

und die Anforderungen.

Der ideale Zustand, auf den wir unser Tun immer wieder ausrichten sollten, ist der

Flow. Hier erleben wir die speziﬁsche Aufgabe als eine hohe Anforderung, aber auch

unsere diesbezüglichen Fähigkeiten sind hoch. Das ist die Grundvoraussetzung, dass wir

in diese Selbstvergessenheit kommen können, in der wir alles um uns und in uns vergessen

und komplett eins sind mit unserer Tätigkeit.

Beispiel

Ein erfahrener Scrum Master kommt in diesen Flow-Zustand gerade dann, wenn sein

Team in einer schwierigen Situation ist. Er spürt, dass die Art und Weise seiner In-

terventionen entscheidend sein werden, damit das Team die aktuelle technische oder

soziale Herausforderung bewältigen kann. Wenn der Scrum Master die Gewissheit hat,

alle Kompetenzen zu haben, um dem Team in dieser Situation zu helfen, wird er ein

Flow-Gefühl erleben können. Sollte er aber merken, dass er mit Phänomenen kon-

frontiert ist, die er nicht versteht, erfährt er in dieser anspruchsvollen Situation einen

Zustand der Erregung, der Angst oder der Sorge. Dies sind alles Aspekte der Überfor-

derung.

Die untere Hälfte des Diagramms zeigt auf, was passiert, wenn ein Mensch mehr Fä-

higkeiten hat als die, die gerade gebraucht werden: Im besten Fall fühlt man sich hier im

Zustand der Kontrolle oder auch der „Komfortzone“. Das ist zwar einen Moment lang

angenehm, aber auf die Dauer befriedigt es nicht. Jeder Mensch braucht für seine eigene

Entwicklung das Gefühl, in einem speziﬁschen Aspekt seines Lebens eine neue Heraus-

forderung bewältigen zu können. Wenn wir also den gleichen, erfahrenen Scrum Master

auf ein sehr einfaches Projekt mit einem kleinen, homogenen Team ansetzen, welches

auch schon viel Erfahrung hat im agilen Projektmanagement, stellt sich bei dieser Person

zwar Entspannung, aber bald Langeweile ein. Der schwierigste Zustand für einen Men-

schen in diesem Modell ist die Apathie. Hier sind wir konfrontiert mit Tätigkeiten für die

wir uns weder qualiﬁziert sehen noch die für uns in irgendeiner Weise eine Herausfor-

derung darstellen. Der Mensch hat in diesem Feld überhaupt nicht das Gefühl etwas zu

tun, was seinen Fähigkeiten entspricht noch hat diese Anforderung einen hohen Anspruch

an ihn. Hier kann sich ein technischer Experte erleben, der nach jahrelanger Forschungs-

tätigkeit plötzlich repetitive Aufgaben in der Produktion übernehmen muss. Oder auch

ein Projektleiter, der nach mehreren großen Projekten mit einer Teilprojektleiter-Aufgabe

beauftragt wird. Unterforderung ist noch gefährlicher als Überforderung!

Dieses Modell liefert eine Orientierungshilfe, wie sich eine Person in einer spezi-

fischen Aufgabe positioniert in Bezug auf die Anforderungen und persönlichen

Fähigkeiten. Je näher wir darin an den Flow kommen, umso gesünder erleben

wir die Belastung. Ja wir merken sogar, dass wir zusätzliche Herausforderungen

304

Mensch

brauchen, um diesen Zustand zu erleben. Die Ausgangspunkte für den Flow

sind die Zonen Kontrolle und Erregung. Die Strategien, um in den Flow zu kom-

men,sinddabeiganz unterschiedlich:Ein Projektleiter,der seinen Mitarbeiter im

Zustand der Erregung wahrnimmt, muss sich darauf fokussieren, dessen Fähig-

keiten noch weiter zuentwickeln,seidiesdurch ein Seminar,eine Weiterbildung

oder durch ein Coaching.Beieinem Mitarbeiter,der sich im Zustand der Kontrol-

le oder gar Entspannung befindet, geht es jedoch darum, wie er sich höheren

Anforderungen stellen kann, beispielsweise über herausfordernde Meilenstei-

ne oder anspruchsvollere Aufgaben.

3.7

Motivation und Sinn

Als wir den Sinn unserer Arbeit nicht mehr sahen, begannen wir über Motivation zu reden

(Reinhard Sprenger).

3.7.1

Zielorientierung des Menschen

Das Konzept der Grundbedürfnisse des Menschen impliziert, dass unser Verhalten ziel-

orientiert ist, und dass sich diese Ziele aus den persönlichen Grundbedürfnissen des Men-

schen ableiten. In Abschn. 3.3.3 ist ausgeführt, wie wichtig das Grundbedürfnis vom

Streben nach Leistung für den Menschen ist und welchen direkten Einﬂuss dies auf posi-

tive Emotionen hat. Durch die Leistung erfahren wir uns wirkungsvoll, können wir unser

expansives und kreatives Potenzial zur Entfaltung bringen.

3.7.2

Was ist Motivation?

Die lateinische Wortwurzel in movitum ire kann übersetzt werden durch: „in das einsteigen,

was (den Menschen) bewegt.“

Grundsätzlich kann Motivation also als Bewegung bezeichnet werden. Entweder

„hin zu“ etwas, genannt Appetit, oder

„weg von“ etwas, genannt Aversion.

Motivation ist aber in keinem Fall Stillstand (Esch 2014, S. 118).

Das Motivationssystem spielt beim Menschen eine wichtige Rolle. Zu Beginn der Evo-

lution hatten die frühen Lebewesen kein Motivationssystem. Man geht heute davon aus,

dass deren motorische Aktivitäten mehr oder weniger auf dem Zufallsprinzip beruhten.

Später wurden die Aktivitäten der Lebewesen gekoppelt an ein System für Wahrnehmung

und Erfahrung. Dieses System wurde wiederum an neuronale Kreisläufe gekoppelt. Somit

3.7

Motivation und Sinn

305

war die Grundlage geschaffen, dass über eine Belohnung genau die Aktivitäten verstärkt

werden konnten, die die Überlebenswahrscheinlichkeit steigerten (Esch 2014, S. 126).

3.7.2.1

Gallup: Engagement und Motivation bei der Arbeit

Seit 2001 wird durch die Gallup-Studie in Deutschland eine repräsentative Umfrage da-

rüber gemacht, wie hoch der Grad der emotionalen Bindung von Mitarbeitern an ihre

Organisation und damit das Engagement und die Motivation bei der Arbeit ist.

Die fünf wichtigsten Faktoren für die emotionale Bindung von Mitarbeitern sind nach

dem Gallup Engagement Index 2016:

Möglichkeit, das tun zu können, was man richtig gut kann

Führungsqualität

Herausfordernde und abwechslungsreiche und als sinnvoll empfundene Tätigkeit

Kollegen und Kolleginnen

Unternehmensziele/Unternehmensphilosophie

Nach Gallup investieren viele Firmen in die falschen Maßnahmen: So wird z. B. „die

Möglichkeit, das tun zu können, was man richtig gut tun kann“ für die emotionale Bindung

als fünfmal wichtiger erachtet als der Lohn.

In diesen fünf wichtigsten Aspekten der emotionalen Bindung spielt der Vorgesetz-

te eine entscheidende Rolle: Das Potenzial, aber auch die Grenzen von Mitarbeitenden

zu erkennen und nach dem Flow-Modell in Abschn. 3.6 zu bewirtschaften, ist eine sehr

anspruchsvolle Aufgabe, sei es für Vorgesetzte in agilen oder klassischen Projektmanage-

ment-Ansätzen. In diesem Aspekt bringt Gallup eine große Diskrepanz zum Vorschein:

Nur gerade 21 % aller Arbeitnehmer sagen von sich, dass die Qualität der Führung, die sie

bei der Arbeit erleben, sie motiviere, eine hervorragende Arbeit zu leisten. Werden aber

die Vorgesetzten zu ihrer eigenen Führungsqualität befragt, halten sich 97 % für eine gute

Führungskraft.

3.7.2.2

Intrinsische und extrinsische Motivation

In der Motivationslehre wird unterschieden zwischen der intrinsischen und der extrinsi-

schen Motivation. Bei der intrinsischen Motivation handelt es sich um eine Eigensteue-

rung, die das freie Fließen der angeborenen menschlichen Energie ermöglicht. Sie moti-

viert die jeweilige Person mit der Frage nach dem Wozu:

Wozu wählt ein Mitarbeiter eine speziﬁsche Firma?

Wozu engagiert sich ein Projektleiter mit all seiner Energie für das Projekt?

Durch die extrinsische Motivation wird eine Person mit Motiven eingedeckt, welche

sie vorher noch nicht hatte. Es handelt sich also um eine Fremdsteuerung. Bei der ex-

trinsischen Motivation steht die Frage nach dem Wie im Mittelpunkt:

306

Mensch

Wie kann ich meine Projektmitarbeiter zu mehr Leistung anspornen?

Wie kann ich sicherstellen, dass mein Team die Jahresziele erreicht?

3.7.2.3

Motivation durch Bearbeitung der Demotivationsfaktoren

Den größten demotivierenden Einﬂuss auf Mitarbeiter übt der direkte Vorgesetzte aus (Rein-

hard Sprenger).

Angelehnt an die „Downside“-Strategie, siehe Abschn. 3.10.5, ist es viel effektiver, die

Ursachen der Demotivation zu bearbeiten statt sich zu fragen, wie die Mitarbeitenden

mehr motiviert werden können (Sprenger 2014, S. 200 ff.). Sprenger machte folgende

Quellen der Demotivation ausﬁndig:

Chef weiß und kann immer mehr

Einsame Entscheidungen

Überzogene und unsachliche Kritik

Dynamisch-lautstarkes Dominanzverhalten

Mitarbeiter wie Luft behandeln

Unzureichende, einseitige, verspätete oder lediglich auf ein speziﬁsches Arbeitsgebiet

reduzierte Informationen

Zur Überprüfung der eigenen Haltung und Einstellung können sich Vorgesetzte folgen-

de Fragen stellen:

Vertraue ich dem Mitarbeiter?

Kenne ich seine Stärken?

Gebe ich ihm Freiräume?

Vereinbare ich die Ziele mit dem Mitarbeiter, oder gebe ich sie vor?

Gebe ich ihm Anerkennung für seine Leistungen?

3.7.3

Sinn als intrinsischer Motivator

Sinn ist das, was Bedeutung hat (Tatjana Schnell).

Ein wesentlicher intrinsischer Motivator ist der Sinn. Die Gallup-Studie weist sinnvolle

Arbeit als wesentlichen Faktor aus. Dieser spielt auch für die persönliche Resilienz eine

wesentliche Rolle (Abschn. 3.8.4).

3.7.3.1

Was ist Sinn?

Der Mensch ist das einzige Lebewesen, das sich die Welt erklären muss, um das Leben zu

bewältigen (Remo Largo).

3.7

Motivation und Sinn

307

„Nur“ seine Grundbedürfnisse zu befriedigen erfüllt den Menschen nicht. Beim Versuch,

sich die Welt zu erklären, stößt der Mensch zwangsläuﬁg auf die Frage nach dem Sinn.

Nach dem Psychotherapeuten Alfried Längle ist der Sinn die gelebte Antwort des Men-

schen auf die Frage nach dem „Wozu“. Der Mensch braucht eine Begründung für das

persönliche Handeln. Er möchte spüren, wozu er da ist und wozu er etwas machen soll

(Längle 2014, S. 10).

3.7.3.2

Lebenssinn ¤ Sinn des Lebens

Wenn wir uns mit der Sinnfrage auseinandersetzen, müssen wir unterscheiden können

zwischen dem Sinn des Lebens und dem Lebenssinn. Ob es grundsätzlich einen Sinn des

Lebens gibt, ist eine philosophische Frage. Was aber konkret erforscht werden kann ist

die Frage, wie ein Mensch seinem Leben Sinn verleiht. Für Tatjana Schnell basiert die

Sinnerfüllung des Menschen auf den folgenden vier Kriterien (Schnell 2016, S. 7 f.):

Kohärenz, Passung: Das Gefühl der Kohärenz stellt sich für den Menschen ein, wenn

er sein Handeln versteht, als stimmig und schlüssig erlebt, wenn die Dinge zusammen-

passen und er in seinen Tätigkeiten Ziele erreichen kann, die für ihn persönlich wertvoll

sind.

Bedeutsamkeit: Hier geht es darum, wie der Mensch die Wirksamkeit seines eige-

nen Handels wahrnimmt. Wenn der Mensch erkennt, dass seine Handlungen positive

Konsequenzen haben für sich selbst und andere, erfährt er Sinnerfüllung.

Orientierung: Jeder Mensch will sich weiterentwickeln können. Auch in unübersicht-

lichen Lebenssituationen will er sich irgendwie orientieren können. Er braucht am

Horizont irgendeine Zielsetzung, die für ihn erstrebenswert ist.

Zugehörigkeit: Der Mensch muss sich als Teil eines größeren Ganzen wahrnehmen

können. Das kann die Familie sein, die Gesellschaft, der Arbeitgeber oder das Projekt-

team. Diese Integration gibt ihm das Gefühl, gebraucht zu werden und Verantwortung

zu haben.

3.7.3.3

Unsere Lebensweise zerstört systematisch Sinn

Nach dem Philosophen Wilhelm Schmid (Schmid 2010) leben wir in einer Zeit, in der

systematisch Sinn zerstört wird: So war früher die Gemeinschaft und damit die Zugehö-

rigkeit zwangsverordnet: In den dörﬂichen Gemeinschaften musste man am öffentlichen

Leben teilnehmen, sei dies durch den Kirchenbesuch oder durch andere Traditionen. Heu-

te leben wir vielmehr als Weltbürger. Dadurch lösen sich viele unserer sinnstiftenden

Beziehungen auf. Aber auch der Spezialisierungsgrad unserer Arbeit nimmt immer mehr

zu. Es ist viel schwieriger, die Wirksamkeit des eigenen Handelns noch erkennen zu kön-

nen.

Eine Person sollte zu ihrer Berufsaufgabe passen. Die Kompetenzen des Menschen

(Abschn. 3.1) sollen den Anforderungen der Berufsaufgabe so gut wie möglich entspre-

chen. Die Gegenüberstellung der gewichteten Kompetenzproﬁle in Abschn. 4.1.12.2 so-

308

Mensch

wie Abschn. 4.1.13.2 machen jedoch deutlich, dass die Anforderungen je Projektrolle

ganz unterschiedlich sein können.

Beispiel

In einer Studie wurden die Teilnehmer gefragt, wie gut sie die Passung (Kohärenz) zu

ihrer Arbeit bewerten würden?

Nur 14 % der Befragten sagten aus, dass die Anforderungen ihrer Arbeit in einer

hohen Passung zu ihren Fähigkeiten stünden.

62 % deﬁnierten die Passung als „mehr oder weniger gut“

das restliche Viertel bewertete die Passung als „nicht gut gematcht“

(Schnell 2016, S. 162).

Es ist also gar nicht selbstverständlich, dass Sie in der Projektarbeit eine Rolle ausüben,

die vollumfänglich zu Ihren Kompetenzen, Charaktereigenschaften und Ihren Interessen

passt. Es wäre wohl auch eine Überforderung, dies zu erwarten. Deshalb stellt sich die

Frage, wieviel Sinnerfüllung vom Beruf überhaupt erwartet werden kann?

3.7.3.4

Sinnerfüllung im Beruf?

Viele Menschen investieren sehr viel Zeit und Energie in ihre Berufstätigkeit. Damit ist

es nur logisch, dass die Erwerbsarbeit auch sinnstiftend sein soll. Wie sollen wir mit der

Sinnerfüllung im Beruf umgehen? Tatjana Schnell äußert sich zu dieser Frage folgender-

maßen: „So wichtig die Sinnhaftigkeit der beruﬂichen Tätigkeit auch ist – das Konzept

sollte nicht überstrapaziert werden. Nicht jeder sucht seinen Lebenssinn in der Arbeit,

und nicht jede Arbeit hat die Qualitäten, die sie zu einem geeigneten Lebensmittelpunkt

werden lassen“ (Schnell 2016, S. 167).

Diese Überlegungen führen zu einem Dilemma: Einerseits braucht der Mensch für

seine Leistungsfähigkeit Motivation, Sinnhaftigkeit oder Flow. Andererseits zeigt das Re-

sultat der oben aufgeführten Studie auf, dass die moderne Erwerbsarbeit genau dies vie-

len Menschen nicht mehr ermöglicht. Wie gehen wir damit um? Die Konsequenz ist,

dass der Mensch die Sinnfrage zwingend ganzheitlich betrachten sollte, über die Be-

rufsarbeit hinaus, wie im Modell der drei persönlichen Lebenswelten ausgeführt wird

(Abschn. 3.10.1).

3.8

Selbstmanagement

Im Zusammenhang mit Burnout hat das Selbstmanagement in der Projektarbeit an Wich-

tigkeit gewonnen. Die Anlage von Projekten ist grundsätzlich herausfordernd: Mit inter-

disziplinären Teams und beschränkten Kosten sollen innovative Ziele erreicht werden.

Irgendwie ist man im Projekt also immer an der Leistungsgrenze. Das hat natürlich auch

3.8

Selbstmanagement

309

Konsequenzen für die persönliche Energiebilanz. Für alle Projektmitarbeiter ist es immer

wieder ein Balance-Akt zwischen der Herausforderung und der Überforderung. In dieser

Balance sind die eigenen Ressourcen optimal zu bewirtschaften. Für Selbstmanagement

gibt es unterschiedliche Deﬁnitionen. Zwei davon seien nachfolgend aufgeführt:

Jäger (2007) versteht unter Selbstmanagement die gezielte, selbstgesteuerte und eigen-

verantwortliche Entwicklung des persönlichen Lebens in die Richtung, die jemand für

sich selber als die beste empﬁndet, um erfolgreich zu sein (In: Steiger und Lippmann

2008, S. 151).

Nach der ICB 4.0 ist Selbstmanagement die Fähigkeit, sich persönliche Ziele zu setzen,

den Fortschritt zu überprüfen und anzupassen, sowie die tägliche Arbeit systematisch

zu erledigen. Selbstmanagement umfasst den Umgang mit sich verändernden Bedin-

gungen und den erfolgreichen Umgang mit Stress (ICB 4.0 PM, S. 53).

3.8.1

Handlungsfähigkeit des Menschen

Gemäß den Deﬁnitionen geht es beim Selbstmanagement immer in irgendeiner Form um

die persönliche Handlungsfähigkeit. Auch in den schwierigsten Situationen schaffen es

Menschen mit einer hohen Selbstmanagement-Kompetenz, Einﬂuss zu nehmen auf das

eigene Fühlen, Denken und Handeln. Wer seine eigene Handlungsfähigkeit verliert, wer

nur noch tut, was von ihm erwartet oder verlangt wird, der lebt ein Leben, welches nicht

mehr seinen persönlichen Vorstellungen, Zielen und Bedürfnissen entspricht. Damit lösen

sich die persönlichen Grenzen immer mehr auf, und die Gefahr für ein Burnout steigt

(Abschn. 3.5.9).

Natürlich haben wir nicht in allem, was wir tun, die freie Wahl. Es gibt Vorgesetz-

te, Auftraggeber oder Kunden, welche Ansprüche und Forderungen an uns stellen, die

wir erfüllen müssen. Für den Schutz der eigenen Handlungsfähigkeit bietet das Modell

vom Bereich der Kontrolle, des Einﬂusses und der Sorge eine wertvolle Orientierung

(Abb. 3.11).

Im Abschn. 3.3.6 ist ausgeführt, dass der Mensch die einzigartige Fähigkeit entwickelt

hat, sein Verhalten von seinen Gefühlen und seiner Intuition zu entkoppeln. Aus dem

heraus lässt sich folgern, dass jeder Mensch einen Bereich der Kontrolle hat, in dem er

selbstbestimmt unterwegs sein kann. Das betrifft grundsätzlich das eigene Fühlen, Denken

und Handeln. In Bezug auf die Projektarbeit beinhaltet dies Bereiche wie die persönliche

Arbeitstechnik, die Kommunikation oder die Gestaltung der Beziehungen. Je nach Funkti-

on und Rolle der jeweiligen Person weitet sich der Bereich der Kontrolle aus: Ein Product

Owner hat klar zugewiesene Entscheidungskompetenzen, ein Scrum Master hat die Kon-

trolle über den Ablauf der Daily Standups.

Für jeden Menschen ist der Kontrollbereich beschränkt. Diesem folgt der Bereich des

Einﬂusses. Ein Projektleiter kann und muss Einﬂuss nehmen auf seinen Projektauftrag.

Der Bereich des Einﬂusses lebt von den konstruktiven Vorschlägen sowie von einer guten

310

Mensch

Sorge

Einﬂuss

Kontrolle

Sorge

Einﬂuss

Kontrolle

Abb. 3.11 Bereich von Kontrolle, Einﬂuss und Sorge

Beziehung und Kommunikation. Im Falle des Projektauftrages macht also der Projektleiter

seinen Einﬂuss auf den Auftraggeber geltend.

Die äußerste Schicht ist der Bereich der Sorge: Wie sich der Weltmarkt entwickelt oder

ob die neue Firmenstrategie erfolgreich sein wird, ist auch mit unserem größten Einsatz

nicht beeinﬂussbar. Deshalb müssen wir uns auch abgrenzen können.

Wer seine Handlungsfähigkeit schützen will, darf sich nicht im Bereich dieser Sorge

verlieren. Hier ist die eingesetzte Energie in einem sehr schlechten Verhältnis zum er-

zielbaren Nutzen. Menschen, die ihre Handlungsfähigkeit bewirtschaften und bewahren

wollen, fokussieren sich auf die Bereiche der Kontrolle und des Einﬂusses.

3.8.2

Persönlicher Kompetenzkreis: Stärken und Schwächen

Ich bin kein Genie. Ich bin punktuell intelligent – aber ich halte mich konsequent um diese

Punkte herum auf (Tom Watson, Gründer von IBM).

Warren Buffet hat den Begriff des „Circle of Competence“ geprägt. Oder zu Deutsch:

Kompetenzkreis. Für Buffet ist der Kompetenzkreis die persönliche Referenzlinie, um

3.8

Selbstmanagement

311

zu entscheiden, was jemand tun und was er lassen soll. Als überaus erfolgreicher Investor

tätigt Buffet nur Anlagen in Firmen, deren Geschäftsmodell er versteht. Falls er dazu nicht

in der Lage ist, kann er auch nicht einen realistischen Firmenwert berechnen und demnach

keine erfolgreichen Anlagen tätigen (Dobelli 2017a, S. 93 ff.).

Buffet darf wohl als Genie seiner Disziplin bezeichnet werden. Trotz seines Erfolges

zeichnet er sich dadurch aus, dass er sich seiner Grenzen bewusst ist. Oder im Um-

kehrschluss: Dadurch, dass sich Buffet seiner Grenzen bewusst ist, ist er so erfolgreich.

Für Buffet ist es übrigens nicht entscheidend, wie groß der Kompetenzkreis ist. Die Welt

ist heute so komplex, dass jeder Mensch nur einen Bruchteil von all dem, was um ihn

herum passiert, verstehen kann. Aber gerade in diesem marginalen Bruchteil liegt der

persönliche Kompetenzkreis, welcher der Startplatz sein kann für einen persönlichen Hö-

henﬂug.

Was macht diesen Kompetenzkreis aus? Die Schulbildung, die Vorlesungen an

der Universität? Für Dobelli ist es die Besessenheit: Es ist das, was Bill Gates an-

getrieben hatte zu programmieren oder Warren Buffet, als er als 12-Jähriger sein

erstesTaschengeldin Aktien investierte.In dasThema,von welchem ein Mensch

besessen ist, wird er über die Jahre tausende von Stunden investieren. Das wie-

derum wird ihn so richtig gut machen in seiner Disziplin.

Der Kompetenzkreis hat auch seine Tücken: Wer immer erfolgreicher wird, meint

plötzlich, in allem gut zu sein. Doch ein Technologie-Experte ist noch lange kein guter

Projektleiter. Oder ein guter Projektleiter ist noch lange kein guter Geschäftsführer. Na-

türlich ist es möglich, den eigenen Kompetenzkreis zu erweitern. Aber das soll bewusst

geschehen, in einem ehrlichen Abwägen der eigenen Stärken und Schwächen und auch

im Bewusstsein, dass dies viel Energie und Aufwand brauchen wird.

3.8.3

Zeitmanagement und Arbeitstechnik

Wie beginnen Sie Ihren Arbeitstag? Kaffee holen, PC starten, E-Mail lesen? Das trifft

wohl für viele zu, die sich als Wissensarbeiter bezeichnen, die ihren Tag im Büro verbrin-

gen und in irgendeiner Form Informationen aufbereiten, transformieren und weitergeben.

Der Mensch ist grundsätzlich neugierig. In den E-Mails und Chat-Tools sieht man, was

läuft. Aber ﬁnden Sie in diesen Tools Ihre persönlichen Prioritäten? Meldet sich da Ih-

re wichtigste Aufgabe für den Tag? Das ist nicht so. Meistens melden sich da Kollegen,

Vorgesetzte oder Kunden, welche Erwartungen an Sie stellen. Wenn Sie nun anfangen, zu

lesen und zu schreiben, versickert Ihre wertvolle Arbeitszeit. Natürlich müssen wir kom-

munizieren, und die digitalen Plattformen haben viele Vorteile. Aber: Für handlungsfähige

Personen sind sie Mittel zum Zweck und nicht Selbstzweck. Selbstwirksame Menschen

legen sich eine Arbeitstechnik zu, die ihnen erlaubt, effektiv ihre persönlichen Prioritäten

zu erreichen. Die Prioritäten sind natürlich ganz unterschiedlich für einen Auftraggeber,

einen Projektleiter oder einen Fachexperten in einem Projekt.

312

Mensch

Notwendigkeit

• Kritischer Pfad

• Problemlösungen

• Ressourcen nicht

verfügbar

• Krisen

• Arbeit unter Zeitdruck

Täuschung

• Viele Meetings

• Viele E-Mails

• Störungen

• Kollegen wollen Arbeit

loswerden

• Dinge, die wir gerne tun

Zeitverschwendung

• Irrelevante Informationen

• cc: E-Mails

• Fluchtaktivitäten

• Social Media, Web,

Smartphone

Qualität

• Planung

• Controlling, magisches

Dreieck

• Innovation

• Stakeholder Management

• Verhandlungen

• Risiko Management

dringend

wichtig

nicht wichtig

nicht dringend

Abb. 3.12 Zeitmanagement-Matrix. (Covey 2014, S. 36)

Wie können Sie Ihre persönlichen Prioritäten erkennen? Das geht nur über Ihre Ziele.

Sie müssen für sich wissen, welche Funktionen Ihnen übertragen worden sind und welche

Ziele Sie damit erreichen müssen. Meistens haben Sie nicht nur die eine Projektarbeit,

sondern arbeiten in mehreren Projekten oder haben auch noch Verantwortlichkeiten in

Linienaufgaben. In seinem Klassiker „Der Weg zum Wesentlichen“ (2014) empﬁehlt Ste-

phen Covey, dass jeder Mensch für sich maximal sieben Rollen deﬁniert (Abschn. 4.1.9).

Je Rolle legen Sie speziﬁsche Ziele fest, aufgrund derer Sie die Prioritäten ableiten kön-

nen. In einem weiteren Schritt teilen Sie die Ziele auch in speziﬁsche Aufgaben auf, die

Sie wiederum durch eine Aufwandschätzung quantiﬁzieren und innerhalb Ihrer persönli-

chen Kapazitäten einplanen.

Bekannt geworden ist Covey’s Zeitmanagement-Matrix (Abb. 3.12), welche zwischen

dringenden und wichtigen Tätigkeiten unterscheidet.

Was ist der Unterschied zwischen dringend und wichtig? Auf dringende Aufgaben

müssen wir reagieren. Sie benötigen sofortige Aufmerksamkeit: Kollegen rufen an, Kun-

den senden uns E-Mails. Es geht um Krisensitzungen, Produktionsausfälle oder kurzfris-

tige Ausfälle von Mitarbeitenden.

3.8

Selbstmanagement

313

Wichtige Aufgaben sind unsichtbar: Hier müssen wir agieren. Wichtige Aufga-

ben tragen zu unseren persönlichen Zielen und Aufgaben bei.

Die Aufgaben, die dringend und wichtig sind, stehen im Quadranten der Notwendig-

keit. Diese müssen sofort erledigt werden. Versäumnisse hätten sofortige Konsequenzen.

Nicht dringende, aber wichtige Aufgaben sind im Quadranten der Qualität aufgeführt.

Es sind dies konzeptionelle Arbeiten wie Planung, Risikomanagement, Stakeholder-Ma-

nagement oder Kommunikation. Meistens sind es nicht Tätigkeiten, die aktiv eingefor-

dert werden. Sehr viel mehr müssen wir auf diese Aufgaben aktiv einwirken. Wird in

der Projektarbeit der Quadrant der Qualität vernachlässigt, ist die Konsequenz absehbar:

Es werden immer mehr operative Probleme in den Quadranten der Notwendigkeit ge-

spült. Die nachlässige Planung führt zu nicht erreichten Meilensteinen, das mangelnde

Risikomanagement generiert massive Zusatzkosten oder das ungenügende Stakeholder-

Management führt zu Widerständen oder Konﬂikten mit Anspruchsgruppen.

Über den Quadranten der Qualität schaffen wir unsere persönliche Handlungs-

fähigkeit. Wer diesen vernachlässigt, wird immer mehr fremdgesteuert und fällt

in den Quadranten der Notwendigkeit.

Zeit gewinnen können wir alle in den Quadranten der Täuschung und Zeitverschwen-

dung: In der Täuschung meinen wir, wir beschäftigen uns mit wichtigen Aufgaben. Aber

in Bezug auf unsere Ziele sind sie es nicht. Zum Beispiel wenn wir einfach aus Gewohn-

heit an Sitzungen teilnehmen, deren Thema aktuell nicht zu unseren Prioritäten gehört.

Oder aber wenn wir uns schlichtweg einfach nur ablenken lassen durch die News auf dem

Smartphone und im Internet oder Neuigkeiten in den sozialen Medien.

Ein aktives Selbstmanagement fordert uns immer wieder neu auf, unser Tun zu re-

ﬂektieren und über diese Matrix einzuordnen. Wer sich über einen großen Teil seiner

Arbeitszeit in einem starken Aktionismus wahrnimmt, muss sich fragen, über welche

Maßnahmen im Quadranten der Qualität er die Menge der Notwendigkeiten reduzieren

kann. In den allermeisten Fällen wird es dann darum gehen, die Arbeit am System zu

intensivieren, wie in Abschn. 1.5.2 ausgeführt. Die Zeit dazu ﬁndet sich im Quadranten

der Täuschung oder der Zeitverschwendung. Das bedingt, dass man sich von nicht mehr

zielführenden Gewohnheiten lösen kann.

3.8.4

Resilienz

3.8.4.1

Was ist Resilienz?

Resilienz ist die Fähigkeit des Menschen, Krisen unbeschadet zu bewältigen und an ihnen zu

wachsen, ja, sogar gestärkt aus ihnen hervorzugehen (Karsten Drath).

314

Mensch

Leistungsvermögen

Zeit

hoch

klein

Normalzustand

Leistungsabfall

Bewältigung

Schädigung

Erholung

Wachstum

Krise

Abb. 3.13 Schematische Funktionsweise von Resilienz. (Drath 2014, S. 102)

Der hohe Leistungsdruck in der Projektarbeit fordert alle Beteiligten in Bezug auf die

persönliche Resilienz stark heraus. Die Wirkungsweise von Resilienz offenbart sich in

verschiedenen Phasen, wie Abb. 3.13 verdeutlicht.

Nach einem Ereignis, welches subjektiv als Krise bewertet wurde – sei das ein ge-

scheitertes Projekt, das Zerbrechen einer (Arbeits-)Beziehung oder der Verlust einer Ar-

beitsstelle – erfolgt im Normalfall bei jedem Menschen ein Leistungsabfall. Man fühlt

sich niedergeschlagen, kann sich nicht mehr konzentrieren oder hat keine Energie mehr.

Im schlimmsten Fall bleibt es nach der Krise bei einer dauerhaften Schädigung der per-

sönlichen Leistungsfähigkeit. Wer Resilienz als Ressource nutzen kann, erlangt seine

Leistungsfähigkeit wieder oder geht gar gestärkt aus der Krise hervor.

Resilienz kann wie ein Muskel trainiert werden. Resilienz kann auch als Reserve ange-

legt werden, um auf zukünftige Schwierigkeiten vorbereitet zu sein. Wer resilient ist, kann

Veränderungen und Umbrüche besser bewältigen. Resilienz ist auch „Elastizität“, Anpas-

sungsfähigkeit, Widerstandsfähigkeit, „seelisches Immunsystem“. Sie lässt Menschen wie

ein Gummiband in ihren normalen Zustand zurückschnellen oder wie ein Stehaufmänn-

chen wiederaufrichten.

3.8

Selbstmanagement

315

3.8.4.2

Grundhaltungen

Monika Gruhl (2008) beschreibt in ihrem Buch „Die Strategie der Stehaufmännchen“,

dass Resilienz im Wesentlichen eine Frage von Grundhaltung und Entwicklung charakter-

licher Fähigkeiten ist.

Optimismus

Das Gute im Schlechten sehen. Das Grübeln stoppen. Positives Selbstbild, Selbstvertrau-

en. Glaube an die Selbstwirksamkeit. Fehlschläge nicht persönlich nehmen. Realistischer

Optimismus: das Positive sehen, ohne die Schwierigkeiten zu ignorieren. „Inmitten der

Schwierigkeiten liegen die Möglichkeiten“. Gewissheit: „Es geht vorbei“.

Akzeptanz

Akzeptieren, dass Unglück, Enttäuschungen und Widrigkeiten zum Leben gehören und

dass sich diese weder vermeiden noch spurlos beseitigen lassen. Sich ausreichend Zeit

nehmen, wahrnehmen, was geschehen ist, Mehrdeutigkeiten (Ambiguitäten) akzeptieren.

Geduld. Dem Werden und der Entwicklung den nötigen Raum geben. Zuversicht, dass sich

die Dinge auch ohne unser Zutun neu ordnen. Vertrauen in einen größeren Sinnzusammen-

hang. Akzeptanz des Unabänderlichen. Selbstakzeptanz: Stärken und Einschränkungen.

Lösungsorientierung

„Wer will, sucht Wege, wer nicht will, sucht Gründe“. Sich Gedanken um Lösungen

machen. Ressourcen aktivieren. Aus der „Problemtrance“ aussteigen. Optionen entwi-

ckeln. Offenheit für neue Ideen und ungewohnte Perspektiven. Flexibilität. Methoden und

Verhaltensweisen wechseln können, wenn sie nicht mehr funktionieren. Kreativ denken.

Neues ausprobieren. Strukturen im Chaos schaffen und organisieren. Auf der Basis dieser

Grundhaltungen entwickeln resiliente Menschen ganz bestimmte Strategien für ihr Den-

ken, Fühlen und Handeln. Dazu sind die folgenden vier charakteristischen Fähigkeiten

wichtig:

Sich selbst regulieren

Gefühle wahrnehmen, aber sich ihnen nicht ausliefern. Sich aktivieren, beruhigen, auf-

heitern. Seine Stimmungen, Antriebe und Reaktionen beeinﬂussen (Selbstkontrolle). Sich

selbst aufbauen. Sich Mut zusprechen. Impulskontrolle. Gefühle und Impulse angemessen

ausdrücken. Wirksame Stressbewältigungstechniken. Intuition.

Verantwortung übernehmen

Die Opferrolle verlassen. Das selbst Beeinﬂussbare erkennen und handeln. Die Verant-

wortung für seine eigenen Gefühle, Gedanken und Taten übernehmen. Das Nichtbeein-

ﬂussbare loslassen. Schuldzuweisungen (an sich oder andere) unterlassen. Antworten auf

die aktuellen Fragen des Lebens („ver-antworten“). Haltungen, Denk- und Verhaltensge-

wohnheiten überprüfen, anpassen und trainieren. Veränderungen aktiv gestalten.

316

Mensch

Beziehungen gestalten

Wohltuende Beziehungen und soziale Netzwerke geben Halt, Verbundenheit und Unter-

stützung. Interesse und Empathie gegenüber anderen und sich selber. Sozialkompetenz.

Soziales Engagement und Gemeinsinn.

Zukunft gestalten

Ein erstrebenswertes, bedeutungsvolles Zukunftsbild haben: Sinn, Werte, Visionen, Träu-

me, innere Bilder und Sehnsucht geben in Krisenzeiten Orientierung. Die Zukunft als

Potenzial sehen. Sein Leben aktiv in die Hand nehmen: Sich für das eigene Wohlerge-

hen weitgehend selbst verantwortlich fühlen. Wissen, was ich langfristig erreichen will.

Einengende Vorannahmen und Glaubenssätze erkennen. Sich auf seine Lebensträume aus-

richten: „Hänge deinen Pﬂug an einen Stern, um gerade Furchen zu ziehen“. Fokussieren.

Handeln.

3.8.5

Umgang mit Scheitern

3.8.5.1

Scheitern bei Roche und Dyson

Severin Schwan, Roche-Konzernchef, legte in seiner Rede am Swiss Economic Forum

2015 die Erfolgsfaktoren des weltweit größten Biotech-Konzerns dar (Müller 2015). Eine

davon lautete: Misserfolge feiern! Weil die Komplexität im Pharmageschäft sehr hoch sei,

würden neun von zehn Projekten scheitern. Durch das Feiern der Misserfolge werde intern

ein Signal gegeben, dass es sich lohnen würde, mit Projekten ein Risiko einzugehen. Und

oft würden die Erkenntnisse aus gescheiterten Projekten Ausgangslage und Grundlage

bilden für die nächsten Projekte.

Leider ist diese Haltung noch nicht in allen Organisationen angekommen. Die Angst,

einen Fehler zu machen, ist vielerorts noch groß. Man fürchtet sich vor dem Reputations-

verlust oder sogar vor Sanktionen. Doch was bedeutet es für Projektbeteiligte, wenn sie

Angst haben vor dem Scheitern? Wo die Angst vor dem Fehler bewusst oder unbewusst

mitschwingt, kann der Mensch sein kreatives Potenzial nicht fruchtbar machen. Gerade in

Projektarbeit, die zum Ziel hat, Innovation zu schaffen, die aufgrund ihrer Anlage immer

auch risikoexponiert ist, braucht es ganz bewusst die von Severin Schwan beschriebene

Haltung und Unternehmenskultur. Nur wer nichts Neues wagt, kann sich in Sicherheit

wiegen, keine Fehler zu machen. Wer aber Innovation schaffen will, bejaht von Anfang

an, dass der Weg ein schwieriger sein wird und dass einem die Früchte des Erfolges nicht

geschenkt werden.

Beispiel

James Dyson sagt von sich selber, dass er 5127 Prototypen bauen musste, bis er den

beutelfreien Staubsauger erﬁnden konnte. Für Dyson beginnt alles mit dem Scheitern:

„Das Scheitern ist der Startpunkt: Wenn etwas scheitert, verstehst du, warum es schei-

tert, und dann beginnst du, darüber nachzudenken, was du tun kannst, um das Scheitern

zu verhindern“ (Brand 2017).

3.8

Selbstmanagement

317

Der Umgang mit dem Scheitern hat also immer zwei Einﬂussfaktoren: Persönliche und

organisationale Anteile.

3.8.5.2

Persönliche Anteile: Haltung

Ute Lauterbach (2007, S. 10) entwickelte für das Scheitern eine einfache Formel:

Scheitern D gewolltes Ziel C nicht erreichen

Scheitern ﬁndet dann statt, wenn wir ein Ziel nicht erreichen können. Grundsätzlich

ist das natürlich unangenehm, beeinträchtigt das Scheitern doch unser Grundbedürfnis

des Strebens nach Leistung. Das wiederum beeinﬂusst unsere Emotionen: Wir fühlen uns

betrübt und traurig.

Natürlich wollen und sollen wir das Scheitern nicht einfach schönreden. Aber um an

eine Haltung eines James Dyson heranzukommen, wird unsere Projektarbeit nicht gelin-

gen, wenn wir jedes Scheitern als persönliche Niederlage wahrnehmen und daraus eine

persönliche Abwertung ableiten.

Basierend auf Lauterbach (2007) können wir uns fragen:

Diene ich dem Scheitern, oder dient das Scheitern mir?

Wenn ich dem Scheitern diene, lasse ich es über mich gewinnen. Ich werte mich ab und

sage mir, dass ich es nicht geschafft habe. Wenn jedoch das Scheitern mir dient, kann ich

mich fragen – so wie Dyson es 5127 mal gemacht hat – was ich daraus lernen kann, wenn

ich mein angestrebtes Ziel nicht erreichen konnte?

3.8.5.3

Organisationale Anteile

Der organisationale Anteil des Scheiterns liegt vor allem in der Organisationskultur, der

Art und Weise, wie wir Probleme lösen (Abschn. 3.4). In vielen Corporate-Identity-Bro-

schüren werden die Mitarbeiter eingeladen, mutig zu sein und Neues zu versuchen. Aber

in der Organisationkultur sind nicht die Hochglanzbroschüren entscheidend, sondern nur,

welches Verhalten der Mitarbeiter belohnt resp. sanktioniert wird. Die für die Organi-

sationskultur relevante Frage ist demnach, welche Erfahrungen die Beteiligten machen,

wenn ein Projekt „gescheitert“ ist? Wird der „Misserfolg“ tatsächlich gefeiert? Wird oh-

ne Schuldzuweisung analysiert, was funktioniert und was nicht funktioniert hat und zu

welchen neuen Einsichten oder Erkenntnissen das Scheitern geführt hat? Wird die Verant-

wortung für das Scheitern von den richtigen (Führungs-)Stellen übernommen, oder wird

sie an die Mitarbeiter delegiert? Erhalten die Projektbeteiligten wieder attraktive Projekte

und werden sogar befördert – oder auf das Abstellgleis gestellt? In diesen Belohnungen

oder Sanktionen äußert sich die wirkliche Organisationskultur. Die allermeisten Mitarbei-

ter richten ihr Verhalten danach aus.

318

Mensch

3.8.5.4

Fail fast

Das Scheitern einer Idee bedeutet nicht, dass die Person, welche die Idee hatte, gescheitert ist

(Biswas 2015).

Dieses Credo im agilen Projektmanagement bringt es auf den Punkt: Scheitern darf kein

Tabu-Thema sein. Vielmehr ist es als ein integraler Bestandteil des Projektmanagements

zu betrachten, welcher über das Risikomanagement systematisch bewirtschaftet wird. Das

agile Projektmanagement provoziert das Scheitern geradezu, indem die Sprint-Planung so

angelegt wird, dass die schwierigsten Aufgaben zuerst angegangen werden. Man will auf

keinen Fall wertvolle Ressourcen in eine wohlfeile Initiative investieren, um in den letzten

Sprint-Zyklen dann herauszuﬁnden, dass der ganze Lösungsansatz nicht funktioniert.

Auch im Silicon Valley wird ein offener Umgang mit dem Scheitern gelebt. Innovation

und Kreativität führen automatisch auch zu einem hohen Risiko und zum Scheitern. Das

allerwichtigste in diesen Erfahrungen ist es – und das ist eine wichtige Haltung für die

Stärkung der eigenen Resilienz – unterscheiden zu können zwischen der persönlichen

Leistung und den Rahmenbedingungen.

Man kann erst aus „Scheiter“-Erfahrungen lernen und sich weiterentwickeln, wenn das

Scheitern einer Idee oder eines Projektes ganz klar weggenommen werden kann von der

Person. Wenn ein Projekt gescheitert ist, heißt das primär nur, dass der technologische

Ansatz, die gewählte Methodik oder etwas anderes nicht funktioniert hat. Möglicherweise

wurde operativ sogar brillantes Projektmanagement betrieben. Unter dieser Perspektive

„dient das Scheitern mir“, und ich werde in der Lage sein, mich durch diese Erfahrung

weiter zu entwickeln.

3.9

Persönliche Kommunikation

3.9.1

Was ist Kommunikation?

Der Begriff „Kommunikation“ ist eine allgemeine Sammelbezeichnung für alle Vorgänge, in

denen eine bestimmte Information gesendet (signalisiert) und empfangen wird, auch wenn es

nicht wechselseitig geschieht (Iris Boneberg).

Wechselseitige Beeinﬂussung wird als Interaktion bezeichnet. Kommunikation dient der

Interaktion. Wesentliche Kennzeichen der zwischenmenschlichen Kommunikation sind:

Kommunikation unterliegt immer einer Interpretation. Was wir als relevante Informa-

tion wahrnehmen, was jeder persönlich für „wahr“ hält, ist das Resultat einer kompli-

zierten selektiven Wahrnehmung (Abschn. 3.3.5). Bei den Anderen entstehen „Wahr-

heiten“, die von meiner „Wahrheit“ abweichen.

Kommunikation ist mehr als Austausch von Informationen. Da jeder Mensch seine

Wirklichkeit subjektiv konstruiert, dient ihm die Kommunikation immer auch zum Ab-

gleich der unterschiedlichen individuellen Konstruktionen.

3.9

Persönliche Kommunikation

319

In der Kommunikation werden immer mehrere Botschaften gleichzeitig gesendet und

wahrgenommen. Die einen sind offen, die andern indirekt, verdeckt. Oft ist das Ver-

deckte jedoch wichtiger als das Offene.

Kommunikation ﬁndet nicht nur zwischen den jeweils Anwesenden statt. Viele Abwe-

sende sind am „Kommunikationsspiel“ im Hintergrund beteiligt, indem sie das Denken

und Reagieren der Anwesenden beeinﬂussen: Was würde wohl der Kunde dazu sagen?

3.9.2

Axiomtheorie

Eine Geste oder eine Miene sagt uns mehr darüber, wie ein anderer über uns denkt, als hundert

Worte (Paul Watzlawick).

Die Qualität der Kommunikation ist das Salz aller Beziehungen. Oft ist die Kommu-

nikation aber auch Grund für Verletzungen und Konﬂikte (Abschn. 4.4.7.7). Unter der

Leitung des Kommunikationswissenschaftlers Paul Watzlawick wurden fünf Axiome ent-

wickelt, welche die Herausforderungen der zwischenmenschlichen Kommunikation dar-

stellen (Krogerus 2017).

1. Man kann nicht nicht kommunizieren

Der Chef kommt am Morgen ins Büro und sagt nichts. Auch das sagt etwas darüber

aus, wie es ihm geht, oder in welcher Beziehung er zu seinen Mitarbeitern steht.

2. Jede Kommunikation hat einen Beziehungs- und einen Inhaltsaspekt

Wer etwas sagt und wie etwas gesagt wird, wiegt immer schwerer als das, was ge-

sagt wird. Der Beziehungsaspekt bestimmt über den Inhaltsaspekt. In konﬂiktreichen

Beziehungen verliert der Inhaltsaspekt fast völlig an Bedeutung (Watzlawick 2011,

S. 63).

3. Kommunikation ist immer Ursache und Wirkung

Die Frau ist genervt, weil der Mann nörgelt. Der Mann nörgelt, weil die Frau genervt

ist.

4. Digitale und analoge Kommunikation

Die verbale Kommunikation wird als digital bezeichnet. Die Nonverbale als analog. In

der zwischenmenschlichen Beziehung hat die analoge Kommunikation einen großen

Einﬂuss, wie das oben aufgeführte Zitat beschreibt.

5. Kommunikation ist symmetrisch oder komplementär

Symmetrisch: Wir reden auf Augenhöhe: Scrum Team

Komplementär: Es herrscht eine Art Hierarchie: Auftraggeber – Projektleiter

3.9.3

Kommunikationsquadrat

Die Axiome 2 und 4 werden von Friedemann Schulz von Thun im Kommunikationsqua-

drat aufgegriffen. In diesem Modell hat jede Nachricht vier Seiten: Neben dem Inhalt, um

320

Mensch

«Ich bin …»

«Du sollst …»

Selbstoffenbarung

Was ich von mir

selbst kundgebe

Appell

Wozu ich Dich

veranlassen möchte

«Es ist …»

«Du bist …»

Beziehung

Was ich von Dir

halte und wie wir

zueinander stehen

Sachinhalt

Worüber ich

informiere

Abb. 3.14 Die 4 Seiten einer Nachricht nach Schulz von Thun

den es vermeintlich immer gehen soll, schwingen die Selbstoffenbarung, die Beziehung

und der Appell mit (Abb. 3.14).

Die Aspekte von Selbstoffenbarung, Beziehung und Appell werden oft nicht wörtlich

(digital), sondern nonverbal (analog) und damit verschlüsselt über die Tonlage, Mimik

oder Gestik zum Ausdruck gebracht. Im Modell von Schulz von Thun sollte der Empfän-

ger entsprechend der vierseitigen Nachricht vier „Ohren“ haben, siehe Abb. 3.15.

Je nachdem, welche Seite einer Nachricht und damit welches Ohr für einen Empfänger

im Vordergrund steht, kann dessen Reaktion ganz unterschiedlich ausfallen.

Beispiel

Während einer Sitzung ist eine Person mit dem Smartphone beschäftigt. Der Projekt-

leiter, der die Sitzung leitet, sieht das. Obwohl die betroffene Person im Moment nicht

verbal auf der Inhalts-Ebene kommuniziert, sendet sie eine Information. Was macht der

Projektleiter mit dieser „Kommunikation“? Wenn er auf dem Beziehungs-Ohr hört,

wird er sich verärgert oder frustriert fühlen. Er interpretiert das Verhalten der Person

so: „Du langweilst mich“, „Dein Geplauder ist unprofessionell“ usw. Hat er ein großes

Appell-Ohr, sucht der Projektleiter den Fehler bei sich und seiner Sitzungsleitung und

3.9

Persönliche Kommunikation

321

Beziehungs-Ohr

Reaktion auf Wert-

schätzung, Nähe,

Distanz, Wärme, Kälte

«Was hält er von mir?»

Sach-Ohr

Konzentration auf die

Sache, auf Objektivität

«Worum geht es?»

Selbstoffenbarungs-Ohr

Was will er mir zu seiner

Person mitteilen?

«Was hält er von sich?»

Appell-Ohr

Was will er von mir?

«Was soll ich tun?»

Abb. 3.15 Das Vier-Ohren-Prinzip nach Schulz von Thun

versucht etwas zu ändern: Schneller zu sprechen oder die Besprechungspunkte efﬁzi-

enter abzuarbeiten. Zwangsläuﬁg wird sich der Projektleiter gestresst fühlen.

Bewusst oder auch unbewusst gibt die Person mit ihrem Smartphone aber auch

etwas von sich selber Preis: Die Selbstoffenbarung. Wenn der Projektleiter die non-

verbale Kommunikation auf dem Selbstoffenbarungs-Kanal empfangen kann, hat

er dafür eine andere Erklärung: z. B. dass die Person möglicherweise in einen sehr

dringenden Geschäftsfall involviert ist. Wer auf der Ebene der Selbstoffenbarung emp-

fangen kann, lässt das Problem und die Ursache für die entsprechende Kommunikation

beim Sender. Er läuft weniger Gefahr, sich von Emotionen beeinﬂussen zu lassen, die

in der aktuellen Situation ungünstig sind.

Günstig ist es, wenn der Projektleiter – evtl. erst nach der Sitzung – die Person damit

konfrontiert, dass ihm die volle Konzentration auf die Sitzung wichtig ist.

In einem solchen Gespräch orientiert sich der Projektleiter von Vorteil an der „Kom-

plettbotschaft“ von Schulz von Thun. Dadurch soll sichergestellt werden, dass möglichst

viel von dem, was gesendet wurde auch gehört wird:

322

Mensch

1. Wenn du . . . (Inhalt: Konkreter Anlass/konkretes Verhalten, was bei mir etwas ausge-

löst hat),

2. fühle ich mich . . . (Selbstoffenbarung: beschreiben, was das mit mir macht).

3. Weil ich . . . (Beziehung: Erklärung, was mir an der Beziehung mit dir wichtig ist),

4. wünsche ich mir von dir . . . (Appell: Wunsch/Erwartung für die Zukunft).

3.9.4

Kommunikationskreislauf

Die Axiomtheorie und das Kommunikationsquadrat werden im Kommunikationskreislauf

zusammengefasst. Wenn ein Mensch eine Nachricht aussenden will, muss er sie in be-

stimmte Worte fassen oder in eine entsprechende Ausdrucksform kleiden. Erwartungen,

Gefühle oder Bedürfnisse werden verschlüsselt in digitale und analoge Kommunikation.

Das erfordert von der Empfangsseite ein entsprechendes Entschlüsseln. Diese Entschlüs-

selung ist ein hochkomplexer Prozess, der u. a. beeinﬂusst ist durch:

die selektive Wahrnehmung mit der Dominanz des Sehsinnes des Menschen (Abschn.

3.3.5)

die Qualität der Beziehung (2. Axiom von Paul Watzlawick).

Unterschiedliche Menschen, Gruppen, Gremien, Organisationen hören und verstehen

anders, geben denselben Worten unterschiedliche Bedeutung und lassen verschiedene Ge-

fühle aufkommen. Missverständnisse sind daher absehbar und normal. Das Resultat des

Entschlüsselungsvorganges ist dann das, was beim Empfänger ankommt; es ist die für ihn

wichtige, relevante Information, die er aufnimmt. Dieser Prozess dreht sich immer wieder

um die folgenden Fragen:

Wahrnehmen: was höre und sehe ich?

Interpretieren und verstehen: was bedeutet das?

Empﬁnden: welche Gefühle löst das in mir aus?

Handeln: wozu veranlasst mich das Gehörte?

Beispiel

Der Projektleiter leitet um 9 Uhr morgens die wöchentliche Projektteam-Sitzung. Einer

der Teilprojektleiter erscheint eine Viertelstunde zu spät und huscht – eine Entschul-

digung murmelnd – auf seinen Platz. In diesem Moment ﬁndet Kommunikation statt.

Auf der inhaltlichen Ebene ist die nonverbale Kommunikation das Zuspätkommen, die

verbale Ebene die gemurmelte Entschuldigung. In dieser Situation sind aus der Pers-

pektive des Projektleiters völlig unterschiedliche Reaktionen möglich:

Der Projektleiter hat eine gute Beziehung zu seinem Kollegen. Eben noch letzte

Woche hat er mit ihm zu Mittag gegessen und dabei erfahren, dass diese Woche

3.9

Persönliche Kommunikation

323

dessen Frau in einer Weiterbildung ist, dass damit sein Kollege alleine die Kinder-

betreuung organisieren muss. Er kennt das, hat Verständnis und nickt dem Kollegen

wohlwollend zu, als er Platz nimmt. Auf der Basis der guten Beziehung deutet er die

Verspätung des Kollegen als Selbstoffenbarung in Bezug auf dessen private Konstel-

lation. Er führt die Sitzung ruhig weiter und informiert den Kollegen danach noch

kurz zu den Punkten, die dieser verpasst hat. Dabei fragt er nach, wie es diesem geht

und klopft diesem aufmunternd auf die Schultern.

Der Projektleiter unterhält nur formale Beziehungen zu seinen Kollegen. Er küm-

mert sich nicht um einen informellen Austausch mit ihnen und ist auf eine professio-

nelle und produktive Arbeitseinstellung fokussiert. Er reagiert auf der Beziehungs-

ebene verletzt, denn er fühlt sich durch dessen Zuspätkommen in seiner Autorität

als Projektleiter nicht respektiert. Er deutet dessen Selbstoffenbarung als „Ich hatte

noch etwas Wichtigeres zu tun“, und möglicherweise als Appell die Aufforderung

„diese Sitzung ist unnötig, alle zwei Wochen würden reichen“. Nach der Sitzung

verschwindet der Projektleiter sofort in sein Büro, ein weiterer Austausch ﬁndet

nicht statt.

Eine identische Situation kann völlig unterschiedliche Konsequenzen hervorrufen. Im

ersten Fall kann sich durch die Solidarität des Projektleiters die Beziehung noch vertiefen.

Im zweiten Fall kann das Vorkommnis der Startpunkt sein für einen Konﬂikt.

3.9.5

Meta-Kommunikation

I Meta-Kommunikation Die Art und Weise, wie wir miteinander kommunizieren, zum

Thema machen.

Der Prozess der Kommunikation besteht normalerweise aus einem Hin und Her von

Senden und Empfangen (3. Axiom von Paul Watzlawick). Es ist ein gemeinsames Spiel

zwischen zwei Seiten, zwischen Aktion und Reaktion. Das bedeutet in einer systemtheo-

retischen Betrachtungsweise, dass nicht das Verhalten nur einer Seite, sondern die Regeln

des Zusammenspiels, das Verhalten beider Seiten und deren gegenseitige Abhängigkeit

betrachtet werden sollen.

Beispiel

Wenn im obigen Beispiel der Projektleiter „einschnappt“, sich nicht respektiert fühlt,

kann er versuchen, seine Autorität noch mehr in den Vordergrund zu stellen. Sollte

der Teilprojektleiter in einem Arbeitspaket in Verzug sein, wird das mit entsprechender

Schärfe kommentiert. Der Projektleiter lässt den Teilprojektleiter nicht an sich her-

ankommen: „Im Moment scheinen wir überall unter Verspätungen zu leiden.“ Der

Teilprojektleiter zieht sich darauf zurück und sagt seinem Projektleiter nicht, dass er

324

Mensch

Absprache,

wie wir miteinander reden

Abb. 3.16 Meta-Kommunikation

von seinem Chef zu einem Projekt mit höherer Priorität angesetzt worden ist. Das führt

zu weiteren Verspätungen. Diese werden vom Projektleiter noch schärfer kritisiert.

Das Verhalten beider ist von demjenigen des Gegenübers abhängig. Das endlose Hin

und Her kann nur durchbrochen werden, wenn beide gemeinsam darüber sprechen, wie

sie miteinander kommunizieren, in Beziehung stehen und was jeder dazu beiträgt, das

Hin und Her aufrecht zu erhalten. Die Absprache darüber, wie wir miteinander reden,

heißt Meta-Kommunikation, siehe Abb. 3.16.

Die Ursache-Wirkung-Rückkoppelung kann nur durchbrochen werden über das

persönliche Gespräch. Im obigen Beispiel wird es darum gehen, dass die beiden

so bald als möglich in einem bilateralen Gespräch das Problem thematisieren.

Dafür ist es nötig, dass sich beide soweit in eine Beziehung einlassen, dass auch

persönliche Aspekte wie die Familiensituation aber auch die emotionale Verlet-

zung thematisiert werden können.Im Gespräch wirdesfür beide Personen dann

darum gehen, vor allem aus der Perspektive der Selbstoffenbarung die Gründe

für das eigene Verhalten oder die Empfindung darlegen zu können. Das bedeu-

tet, dass von beiden hohe kommunikative Kompetenzen gefragt sind, wie z. B.

die Ich-Botschaft oder das aktive Zuhören.

3.9

Persönliche Kommunikation

325

3.9.6

Ich- und Du Botschaft

In der verbalen Kommunikation macht es einen großen Unterschied, ob wir mit einer Ich-

Botschaft oder einer Du-Botschaft unterwegs sind. Mit einer Aussage, die mit einem „Ich“

beginnt, beziehe ich mich auf mich selber:

Ich bin mit dem Ergebnis deiner Arbeit nicht zu frieden.

Ich ärgere mich, wenn du zu spät zu unserem Termin kommst.

Ich bin in Sorge, dass wir diesen Kunden verlieren, wenn du so mit ihm sprichst.

Damit betone ich in meiner Aussage, die Subjektivität meiner Wahrnehmung und deren

Bewertung. Ich beschreibe auf der Ebene der Selbstoffenbarung, wie etwas oder jemand

auf mich wirkt.

Wenn ich hingegen Du-Botschaften sende, setze ich meine Wertung in den Mittelpunkt.

Ich kommuniziere nicht mehr auf Augenhöhe, sondern nehme für mich in Anspruch, eine

andere Person zu maßregeln:

Das hast du falsch gemacht.

Du solltest auf deine Pünktlichkeit achten.

So darfst du nicht mit dem Kunden sprechen.

3.9.7

Feedback

In der Projektarbeit ﬁndet Kommunikation oftmals im Zusammenhang mit der Steuerung

von Prozessen statt. Dies bedeutet, dass ich das Verhalten von Personen ansprechen muss.

Dies kann in positiven Fällen (Bestätigung einer Leistung, eines Resultates) aber auch in

negativen Fällen (nicht erbrachte Leistung, Kritik, Fehlverhalten) stattﬁnden. Diese Rück-

meldung zum Verhalten wird als Feedback bezeichnet.

Feedback ist eine Mitteilung an eine Person, die diese darüber informiert, wie ihre Verhal-

tensweisen von anderen wahrgenommen, verstanden und erlebt werden (Klaus Antons).

Das Feedback ist auch ein wesentlicher Bestandteil, wenn ich eine Kritik anbringen

will. Die Art und Weise, wie diese Kritik formuliert wird, deﬁniert die Kultur und den

Führungsstil in einer Organisation. Ist es eine Rückmeldung zu einem Verhalten mit dem

Wunsch, das Verhalten zu überdenken und zu ändern, oder ist es ein Anordnen und Zu-

rechtweisen?

326

Mensch

verschlüsseln

entschlüsseln

Feedback

Empfänger

Sender

Selektive

Wahrnehmung

Selektive

Wahrnehmung

Äusserung

Sachinhalt

Beziehungshinweis

Selbstkundgabe

Appell

Abb. 3.17 Kommunikationskreislauf

3.9.7.1

Johari-Fenster

Ich weiß nicht, was ich gesagt habe, solange ich nicht die Antwort darauf gehört habe (Nor-

bert Wiener).

Feedback ist eine Chance, etwas über sein Wirken auf andere zu erfahren sowie die ei-

gene Verhaltensweise zu überprüfen und allenfalls zu verändern. Feedback kann auch

Beziehungen klären. Die Antwort kann verbal, aber auch durch nonverbale Reaktion im

Verhalten des anderen auf eine Äußerung hin erfolgen. Insofern erhalten und geben wir

ständig Feedback, oft, ohne dass darüber ein Wort gesprochen wird. Durch Feedback ﬁn-

det also die Rückkoppelung zwischen Sender und Empfänger statt (Abb. 3.17).

Somit ist das Feedback eines der zentralen Instrumente der Teamentwicklung. Im agi-

len Ansatz hat dieses in der Sprint Retrospektive einen festen Platz. Wenn wir unsere

soziale Kompetenz erweitern wollen, sind wir gezwungen, immer wieder über die Wir-

kung unseres eigenen Verhaltens von anderen zu erfahren. Gleichzeitig überprüfen wir

auch, was Aktionen anderer bei uns auslösen.

Nun gibt es Dinge, die wir von uns selbst kennen und solche, die wir nicht kennen.

Ebenso gibt es Dinge, die wir anderen frei zugänglich machen und solche, die wir für

uns behalten. Hierzu haben die beiden Sozialpsychologen Joseph Luft und Harry Ingham

3.9

Persönliche Kommunikation

327

1. Öffentliche Person

Arena des freien Han-

delns: Bereich, der allen

und mir bekannt ist

3. Blinder Fleck

Wie andere mich wahr-

nehmen und erleben, mir

aber nicht bekannt ist

4. Unbewusstes

Weder mir noch

anderen zugänglich

2. Soziale Fassade

Verborgenes: meine

Privatsphäre, meine

Geheimnisse und Be-

dürfnisse, die ich

nicht mitteilen möchte

mir bekannt

mir unbekannt

anderen bekannt

anderen unbekannt

Abb. 3.18 Johari-Fenster

ein Teamentwicklungsmodell entworfen: Das Johari-Fenster (Abb. 3.18). Es hilft uns, die

interpersonalen Beziehungen besser wahrzunehmen.

Dank unserem Bewusstsein und der Selbstreﬂexionsfähigkeit (Abschn. 3.3.6) ist es

uns möglich, uns selber wahrzunehmen. Dies stellen in Abb. 3.18 die beiden Felder „Mir

bekannt“ dar. Einen Teil davon bin ich bereit, im Sinne der öffentlichen Person mit anderen

zu teilen. In der Berufsarbeit sind wir aber meistens nicht bereit, die ganze Privatsphäre

mit den Kollegen zu teilen. Diesen uns bewussten und bekannten Teil unserer Person

bezeichnen Luft und Ingham als „soziale Fassade“.

Beispiel

Ein stets elegant gekleideter Product Owner der Finanzindustrie liebt es, am Wochenen-

de in der schwarzen Lederjacke mit seiner Harley-Davidson eine Ausfahrt zu machen.

Diese „Soziale Fassade“ teilt er nur mit seinem Assistenten.

Für Feedback relevant ist vor allem der „Blinde Fleck“. Das sind die Aspekte von

unserem Verhalten, die uns selber nicht bewusst sind, anderen jedoch ins Auge stechen.

328

Mensch

Beispiel

Im Normalfall ist der Product Owner eine gewinnende Person. Er nimmt sich Zeit für

die Teammitglieder und kann gut zuhören. In den vergangenen Projekten hatte er auch

eine gute Abstimmung mit dem Scrum Master und ließ diesen intervenieren, wenn

es darum ging, Hindernisse aus dem Weg zu räumen. Das aktuelle Projekt verläuft

schwierig, zudem wurde ein neuer Scrum Master zugewiesen mit wenig Berufserfah-

rung. Wenn dieser nun Vorschläge unterbreitet, wirkt der Product Owner ungeduldig,

lässt diesen nicht ausreden und kritisiert dessen Vorschläge.

Durch den schwierigen Verlauf des Projektes ist der Product Owner stärker unter Stress.

Zudem versteht er nicht, dass ihm gerade für das aktuelle, wichtige strategische Projekt

ein neuer Scrum Master zugewiesen worden ist. Unter diesen Umständen ist das Feed-

back von etablierten Arbeitskollegen des Product Owners sehr wertvoll. Diese können

ihm bewusst machen, was sich da in seinem Verhalten und auch in der Kommunikation

mit dem Scrum Master abspielt und wie sich das verändert hat im Vergleich zu den vorhe-

rigen Projekten. Dadurch kann dies bewusst gemacht und schließlich auch im Sinne einer

Teamentwicklung bearbeitet werden.

Natürlich hat jeder Mensch auch noch einen unbewussten Teil. Der bleibt einer Person

selber wie auch ihrem Umfeld verborgen.

3.9.7.2

Johari-Fenster in der persönlichen Weiterentwicklung

Das Johari-Fenster dient auch zur Orientierung für die persönliche Weiterentwicklung: Je

mehr sich eine Person für Feedback öffnen kann, desto besser kann sie Selbstbild und

Fremdbild aufeinander abstimmen und damit den blinden Fleck minimieren. Der Neben-

effekt von Feedback ist meist, dass mehr Vertrauen in den Beziehungen entsteht. Das

erlaubt wiederum, offener zu sein in Bezug auf die persönlichen Bedürfnisse und diejeni-

gen der Kollegen. So wird die soziale Fassade zugunsten der öffentlichen Person abgebaut

(Abb. 3.19).

3.9.7.3

Feedbackregeln

Feedback hat für die persönliche Weiterentwicklung wie auch für die Teamentwicklung

eine zentrale Bedeutung. Damit wir konstruktiv mit Feedback umgehen können, sind fol-

gende Regeln einzuhalten:

Grundsätzliche Feedbackregeln

„Ich-Botschaften“ statt „Du-Aussagen“

Konkret statt allgemein

Wahrnehmung und Interpretation auseinanderhalten

Feedback annehmen ohne Verteidigung und Rechtfertigung

Feedback ist meine subjektive Wahrnehmung eines Verhaltens

3.9

Persönliche Kommunikation

329

mir bekannt

mir unbekannt

anderen bekannt

anderen unbekannt

Die Zusammenarbeit wird

erleichtert, durch die Er-

weiterung des Bereichs des

freien Handelns

Veränderung

durch aktives

Feedback

geben und

nehmen

Veränderung durch

Offenheit für eigene und

andere Vorstellungen

und Bedürfnisse

Abb. 3.19 Johari-Fenster für die persönliche Weiterentwicklung

Feedback geben

Konkret: Ich formuliere konkrete Aussagen, wie ich es erlebe, wahrnehme, wie etwas

auf mich wirkt

Beschreibend: Ich mache möglichst genaue Beschreibungen und interpretiere nicht

Realistisch: Ich halte Maß und passe mein Feedback der Situation an

Sofort: Ich gebe das Feedback so schnell wie möglich, um den Fokus auf das Wesent-

liche zu ermöglichen

Verlangt: Ich zwinge mein Feedback dem Gegenüber nicht auf

Relativiert: Ich formuliere „Ich-Botschaften“ und bewerte nicht

Feedback erhalten

Ausreden lassen: Feedbackgeber nicht unterbrechen

Keine Verteidigung: Durch Nachfragen die Wahrnehmung des Gegenübers konkreti-

sieren

Grenzen setzen: Ich formuliere, welche Informationen ich will

Annehmen: Ich argumentiere nicht, rechtfertige oder verteidige mich nicht

330

Mensch

Prüfen: Ich überprüfe die Bedeutung der Aussagen für mich persönlich

Danken: Ich bedanke mich für jedes Feedback, auch wenn es in einer unangebrachten

Weise gegeben wurde

Zeit lassen: Ich lasse mir Zeit für die Prüfung der Bedeutung der Aussagen für mich

persönlich und teile meine Reaktionen mit, wenn es für mich stimmt

Wirkung von Feedback

Feedback erlaubt mir zu lernen, wie ich von anderen Menschen wahrgenommen werde

Feedback verstärkt positive Verhaltensweisen

Feedback dient der Klärung von Beziehungen zwischen Menschen

Feedback korrigiert Verhaltensweisen, die der Gruppe nicht weiterhelfen

Feedback hilft, die Wahrnehmung und das Verhalten der Anderen besser zu verstehen

3.9.8

Fragetechniken

Ein offenes Herz und ein offener Geist sind davon abhängig, dass wir nicht aufhören zu

fragen. Ein Ausrufezeichen setzt allem immer ein Ende (Bertrand Piccard).

Nach dem systemischen Weltbild (Abschn. 1.6.4) können wir nie „wissen“, welche Wahr-

nehmung eine andere Person hat, was jemand denkt, wie es ihr geht oder was sie stört.

Der einzige Weg, dies herauszuﬁnden ist, Fragen zu stellen.

3.9.8.1

Offene und geschlossene Fragen

Grundsätzlich gibt es keine falschen Fragen. Die Kunst der Fragetechnik liegt darin, je-

weils die passende Frage zu stellen, welche mir in einer speziﬁschen Situation hilft, zu der

Information zu kommen, die ich mir wünsche.

Geschlossene Fragen helfen mir, Fakten sicherzustellen oder Information zu bestätigen.

Sie können oder sollen mit einem „Ja“ oder „Nein“, oder mit einer speziﬁschen Informa-

tion beantwortet werden.

Kommst du mit deinem Vorgesetzten klar?

Was ist deine Muttersprache?

Wann gehst du heute?

Ist das ein Foto deiner Kinder?

Dem stehen die offenen Fragen gegenüber. Diese sollen . . .

bei meinen Gesprächspartnern neue Gedankenprozesse und Reﬂexionen stimulieren

die Befragten stimulieren, ihre Gedanken zu äußern

dazu anregen, Neues zu ﬁnden, aus einer Denkblockade herausführen

3.9

Persönliche Kommunikation

331

Wer

Was

Wann

Wie

Warum

Abb. 3.20 Offene und geschlossene Fragen

möglichst viel Information liefern, klärend wirken

ermöglichen, unterschiedliche Standpunkte und Perspektiven zu beleuchten

Alle Fragen, die mit „W“ beginnen, können als offene Fragen formuliert werden

(Abb. 3.20).

Wie kommst du mit deinem Vorgesetzten klar?

Wo kommt deine Familie her?

Was sind deine Pläne für heute Abend?

Wer sind die Kinder auf dem Foto?

Wenn ich mein Gespräch über offene Fragen führe, überlasse ich meinem Gegenüber

die Wahl, welche Informationen in welcher Offenheit oder Vertraulichkeit es mit mir tei-

len möchte. Die Frage nach den Kindern auf dem Foto lässt sich kurz beantworten. Das

Gegenüber kann auch auf einer vertraulichen Beziehungsebene vom letzten Urlaub erzäh-

len, während dem das Foto möglicherweise entstanden ist. Über die offene Frage setze

ich keinen Druck auf, ich führe kein Verhör durch wie mit geschlossenen Fragen, son-

dern bewege mich wie ein Archäologe von Frage zu Frage und beobachte, was sich mir

offenbart.

332

Mensch

„W-Fragen“ dürfen jedoch nicht blindlings als offene Fragen behandelt werden. Ge-

nauso können daraus geschlossene Fragen formuliert werden:

Wer moderiert die Sitzung?

Wann gehst du heute Abend nach Hause?

Wo werden die Projektdokumente verwaltet?

Was ist das Projektbudget?

Auch das „Warum?“ soll sorgfältig eingesetzt werden, kann es doch das Gegenüber in

eine Verteidigungshaltung bringen.

Warum ist die Machbarkeitsstudie noch nicht abgeschlossen?

3.9.8.2

Aktives Zuhören

Technik

Im Kommunikationskreislauf (Abschn. 3.9.4) ist es unmöglich, dass etwas genauso de-

codiert wurde wie es codiert wurde. Die „Übersetzungsfehler“ kann ich durch das aktive

Zuhören erkennen und korrigieren.

Aktives Zuhören bedeutet immer „Verstehen Wollen“. Einerseits kann der Empfänger

einer Nachricht dem Absender zurückspiegeln, was er verstanden hat. Ich kann aktives

Zuhören aber auch in Sitzungen verwenden, wenn ich das Gefühl habe, dass die Sitzungs-

teilnehmer aneinander vorbeireden, wenn ich etwas genau auf den Punkt bringen will oder

auch, wenn ich das Gesprächstempo reduzieren möchte.

Dem ursprünglichen Sender der Nachricht erlaubt das aktive Zuhören, entweder eine

Information zu bestätigen oder aber auch diese nochmals präziser zu formulieren resp.

beim Gegenüber nicht beabsichtigte Rückschlüsse zu korrigieren.

Beispiel

So kann durch das aktive Zuhören überprüft werden, ob die Aussage des Gegenübers

richtig verstanden worden ist:

„Habe ich dich richtig verstanden, dass du den neuen Entwurf der Machbarkeitsstu-

die per Ende September abschließen wirst?“

„In meinen Worten formuliert würde das heißen, dass wir das Lastenheft dem Kun-

den noch nicht zustellen können, bevor der Leiter der Entwicklung die Testresultate

für den Prototyp bestätigt?“

Aktives Zuhören als Grundhaltung und Entwicklungsunterstützung

In der Erweiterung des Begriffes des Aktiven Zuhörens, wie ihn ursprünglich der ameri-

kanische Psychologe und Psychotherapeut Carl Rogers 1942 als Technik beschrieb, Frie-

demann Schulz von Thun 2005 als Grundhaltung und Eric Lippmann 2013 als Coaching-

3.9

Persönliche Kommunikation

333

1. Stufe

2. Stufe

Kernaussage formulieren

Zusammenfassen
Spiegeln
Feedback

«Es auf den

Punkt bringen»

Lösung entwickeln

Hypothesen
Vermutungen
Lösungsszenarien

«Ich werde tun!»

3. Stufe

Beziehung herstellen

Blickkontakt
Rahmen schaffen
Zuhörend nicken

«Ich bin ganz Ohr»

Abb. 3.21 Aktives Zuhören als Grundhaltung und Entwicklungsunterstützung

Intervention formulierte, kann im aktiven Zuhören eine effektive Coaching-Methode ge-

sehen werden (Abb. 3.21). In diesem Coaching geht es nicht nur um ein dreistuﬁges,

„einfühlsames verstehen Wollen“ nach Schulz von Thun oder darum, die inhaltliche

und die emotionale Ebene seines Gegenübers zurückzumelden (Lippmann), sondern im

dritten Schritt den Coachee durch weitere Rückfragen, Vermutungen, Hypothesen oder

Lösungsvorschläge zu unterstützen, eigene passende Lösungsvorschläge zu entwickeln

und zu bewerten.

1. Stufe: Präsenz schaffen

Auf der Beziehungsebene dem Gesprächspartner signalisieren, dass ich „ganz Ohr“ bin. In

dieser Phase werden der Rahmen für das weitere Gespräch geschaffen und das Vertrauen

aufgebaut, welches später nötig ist, damit auch persönliche Rückmeldungen möglich sind.

2. Stufe: Verbalisieren

Durch Nachfragen und Zusammenfassen wird versucht, das Wesentliche herauszuarbei-

ten. Hier ist es wichtig, dass die Interessen sichtbar werden. Es gehört auch Feedback zur

Situation dazu, ebenso wie Spiegelungen, wie der Gesprächspartner aktuell wahrgenom-

men wird. Hier soll der Befragte sein Anliegen „auf den Punkt bringen“ können.

334

Mensch

3. Stufe: Entwickeln

Mittels unterstützenden Fragen, Hypothesen, Vermutungen und weiteren systemischen

Fragen wird der Coachee unterstützt, eigene Lösungsszenarien zu entwickeln und zu

analysieren. Das Ziel ist, dass der Coachee eine „für ihn realistische Lösung“ für seine

Fragestellung erkennt und plant.

Der Coach achtet darauf, dass der Coachee aktiv bleibt und seine Fragestellung bear-

beitet. Dabei soll der Coach genügend zurückhaltend bleiben, Denkpausen, „Lösungslo-

sigkeit“, wie es Schulz von Thun nennt, aushalten. Es geht auch nicht darum, möglichst

viele Fragen zu stellen oder Rückmeldungen zu geben, sondern vielmehr, die Führung

und Bearbeitung dem Coachee weitgehend zu überlassen und ihm in seinen Gedanken

und Ansätzen zu folgen und ihm zu helfen, dass er Nebensächliches weglässt und sich auf

die Bearbeitung der eigentlichen Fragestellung konzentrieren kann.

3.9.8.3

Weitere Fragetypen

Nachfolgend sind weitere Fragetypen ausgeführt, die helfen können, im offenen Geist des

Fragens zu bleiben:

Zirkuläre Fragen erlauben es, die Perspektiven anderer Personen in das Gespräch ein-

zubeziehen und dadurch weitere Perspektiven einzubinden:

„Wenn ich Ihren Vorgesetzten fragen würde, was würde er mir sagen?“

Zielorientierte Fragen erlauben es, eine Zielsetzung klar zu deﬁnieren:

„Wie können Sie feststellen, ob das Ziel erreicht wurde?“

Ressourcenorientierte Fragen werden in schwierigen Situationen eingesetzt, um dem

Gegenüber zu helfen, sich seiner Potenziale bewusst zu werden:

„Gab es eine Zeit, in der das Arbeitsklima besser war?“

Skala-Fragen fordern das Gegenüber auf, aus der emotionalen Ebene auf die rationale

Ebene zu wechseln und einer Situation eine Bewertung zu geben:

„Auf einer Skala von 1–10, wie würden Sie Ihre Leistung einschätzen?“

Hypothetische Fragen leiten das Gegenüber an, aufgrund einer Annahme ein Szenario

nochmals zu durchdenken:

„Wenn A das Projektteam verlassen würde, welche Konsequenzen hätte das auf die

Teamleistung?“

Die Herzfrage dient dazu, Positionen zu hinterfragen, um herauszuﬁnden, was einer

Person am Herzen liegt:

„Was genau ist Ihnen dabei wichtig?“

3.10

Persönliche Weiterentwicklung

335

3.10

Persönliche Weiterentwicklung

Wir können nicht irgendein Leben führen, sondern nur unser eigenes (Remo Largo).

In Abschn. 3.5.4 sind die drei dem Menschen zur Verfügung stehenden Strategien im Um-

gang mit Herausforderungen – und damit auch für die persönliche Weiterentwicklung –

ausgeführt: Verändern, Neubewerten oder Verdrängen. Hier werden weitere Aspekte dar-

gestellt, die den Leser in seiner persönlichen Weiterentwicklung unterstützen können.

3.10.1

Die drei Lebenswelten

Die Berufswahl, die Sie zum Projektmanagement gebracht hat, ist hoffentlich nicht nur

Zufall, sondern hat auch etwas mit Ihren Grundbedürfnissen (Abschn. 3.3.3) und Kompe-

tenzen (Abschn. 3.1) zu tun.

Die Erwerbsarbeit ist für viele Menschen in unserem Kulturkreis der Lebensmittel-

punkt. Die Ausführungen zum Thema Sinn zeigen, dass es eine Überforderung an die

Erwerbsarbeit wäre, darin eine sehr hohe Passung zu erwarten (Abschn. 3.7.3.3). Des-

halb ist es wichtig, in der eigenverantwortlichen Weiterentwicklung einen ganzheitlichen

Ansatz zu verfolgen. Dazu hilft das Modell der drei Lebenswelten (Abb. 3.22).

In diesem Modell steht die Arbeitswelt auf dem Fundament von Beziehungs- und

Eigenwelt. Mit der Arbeitswelt wird natürlich nicht nur die Erwerbsarbeit verstanden,

sondern auch die Familien- oder Freiwilligenarbeit.

Der Mensch als soziales Wesen braucht aber mehr für eine gelingende Existenz, als

„nur“ die Arbeit. Vor allem die Qualität unserer Beziehungen hat einen wesentlichen Ein-

ﬂuss auf unser psychisches Wohlbeﬁnden. Natürlich wollen wir auch in der Arbeitswelt

gute Beziehungen pﬂegen. Aber in diesem Bereich sind die Beziehungen immer auch

geprägt von Positionen, Rollen, Macht oder Organisationskulturen. In wirklich authenti-

schen Beziehungen können wir uns so geben, wie es uns zumute ist. Wir müssen keine

Rollen spielen und sind nicht in Machtverhältnisse eingebunden. Während die Beziehun-

gen der Arbeitswelt auf Respekt und Anerkennung basieren, soll die Beziehungswelt von

Liebe und Zuneigung geprägt sein.

Die Eigenwelt bildet den Raum für unsere persönlichen Interessen, Hobbies und auch

für den erweiterten Freundeskreis.

Konflikte und Krisen können uns in der Erwerbsarbeit jederzeit ereilen, auch

ganz unverschuldet. Dann wird eine Traumstelle plötzlich zu einer schweren

Last. Je besser wir in guten Zeiten die Beziehungs- und Eigenwelt pflegen, des-

to mehr können wir uns auf sie verlassen, wenn uns unvorbereitet eine Krise in

der Arbeitswelt trifft. In solchen (Stress-)Situationen hilft vor allem die Nähe zu

unseren Mitmenschen (Abschn. 3.5.8).

336

Mensch

Arbeitswelt

Arbeit

Beruf

Beziehungswelt

Partnerschaft

Familie

Eigenwelt

Raum für sich selbst

und andere(s)

Abb. 3.22 Lebenswelten des Menschen. (Basierend auf: Walser und Wild 2002)

3.10.2

Selbsterkenntnis

Jeder Mensch hat seine eigene Persönlichkeit, Charaktereigenschaften, Stärken und

Schwächen. Die Persönlichkeit eines erwachsenen Menschen kann nur wenig verän-

dert werden; Sie ist zu wesentlichen Teilen das Resultat der genetischen Veranlagung

sowie der Sozialisation und der prägenden Lebenserfahrungen. Viel wichtiger als die

Veränderung ist in der Persönlichkeitsentwicklung, sich selber immer besser zu kennen

und zu bejahen. Mit diesen Kenntnissen suche oder entwickle man ein Arbeitsumfeld,

welches so gut wie möglich zu den eigenen Persönlichkeitsmerkmalen passt. Für diesen

Prozess der Bewusstwerdung stehen zwei grundsätzlich unterschiedliche Verfahren zur

Verfügung.

Persönlichkeitstypologien

Typologien, wie Belbins Teamrollen oder der Golden Proﬁler of Personality (GPOP) von

Golden, Bents und Blank beruhen auf empirischen Beobachtungen. Der Charakter eines

Menschen wird dabei unterschiedlichen Typen zugeordnet. Schon in der Antike wur-

de versucht, auf Grund von menschlichem Verhalten Typologien der unterschiedlichen

Persönlichkeiten herzuleiten. So beschrieb zum Beispiel Empedokles (495–435 v. Chr.)

3.10

Persönliche Weiterentwicklung

337

Typen, die auf den vier Grundelementen Luft, Wasser, Feuer und Erde aufbauten. Hippo-

krates (460–377 v. Chr.) beschrieb vier menschliche Temperamente, ausgehend von den

vier Körpersäften Blut, Schleim, gelbe und schwarze Galle, welche den Menschen un-

terschiedlich prägen. Diesen ordnete ca. 200 Jahre später der römische Arzt Galenus die

noch heute bekannten Typen Sanguiniker, Phlegmatiker, Choleriker und Melancholiker

zu. In der Moderne orientierte sich Ernst Kretschmer (1888–1964) mehr am Körperbau

und leitete daraus die Charaktere ab. In seiner Konstitutionstypologie deﬁnierte er die

Typen Leptosomer, Pykniker und Athletiker.

Psychometrische Verfahren

Das Verhalten von Menschen wird abgeleitet aus dem wissenschaftlichen Messen ver-

schiedenster Verhaltensweisen, Motive, Einstellungen und Werte. Diese psychologischen

Testverfahren ﬁnden Anwendung in Assessments, unter anderem in der Personal-,

Verkehrs-, Schul-, und Rechtspsychologie. Beispiele für dieses Verfahren sind Work-

place Big Five (WPB5) oder das Reiss Motivation Proﬁle.

Nachfolgend werden zwei Persönlichkeitstypologien vorgestellt:

3.10.2.1

Belbin

Wie verhalten Sie sich in Teams? Oder noch speziﬁscher: Wie verhalten Sie sich unter

Stress oder in Konﬂikten? Wenn Sie ehrlich sind, können Sie diese Frage nicht genau

beantworten. Denn in diesen Ausnahmesituationen verliert der Mensch seine Fähigkeit

zur Selbstreﬂexion (Abschn. 3.3.6). Aber Sie haben Experten um sich herum, die Ihnen

ganz genau sagen können, wie Sie sich in diesen Ausnahmesituationen verhalten: Ihre

Kollegen und Mitarbeiter. Denn diese haben Sie schon oft in solchen Situationen erlebt

und beobachtet. Ihr Feedback (Abschn. 3.9.7) verhilft Ihnen zur Selbsterkenntnis. Das

Konzept der Belbin Teamrollen kann auf zwei Ebenen eingesetzt werden:

Persönliche Selbsterkenntnis: Belbin bildet eine strukturierte Möglichkeit, Ihren per-

sönlichen blinden Fleck aufgrund einer Gegenüberstellung von Selbstbild und Fremd-

bild bewusst zu machen (nachfolgend beschrieben).

Erfolgsfaktoren der Zusammenarbeit: Das Belbin Konzept erlaubt es, möglichst

ausgeglichene und damit auch leistungsfähige Teams zusammenzustellen. Darauf wird

in Abschn. 4.1.14.1 eingegangen.

Belbin Grundlagen

Meredith Belbin hat das Konzept der Belbin Teamrollen aus der Fragestellung heraus

entwickelt, weshalb gewisse Teams Erfolg haben und andere scheitern. Er entwickelte

ein Management-Spiel, in welchem das Arbeitsleben simuliert wurde. Dieses enthielt

alle Hauptvariablen, die für die Probleme der Entscheidungsﬁndung in Organisationen

typisch sind. Dann wurden aus Probanden verschiedenartige Unternehmens-Teams gebil-

det. Die Teammitglieder wurden ihrerseits über psychometrische Tests sowie mit einem

338

Mensch

Test der Denkfähigkeit auf hohem Niveau (Critical Thinking Appraisal) in ihrer Persön-

lichkeit erfasst. Während der Durchführung des Management-Spiels wurden die Beiträge

der einzelnen Teammitglieder wissenschaftlich erfasst. Am Schluss des Spiels wurde der

wirtschaftliche Erfolg des Teams gemessen (Bergander 2008).

Was ist eine Teamrolle?

Unter einer Teamrolle versteht Belbin: „Eine bestimmte Art, sich zu verhalten, sich einzu-

bringen und mit anderen zu interagieren“ (Bergander 2008).

Eine wesentliche Erkenntnis in Bezug auf die einzelnen Teilnehmer war, dass sie sich in

derselben Situation ganz unterschiedlich verhielten. Diese unterschiedlichen Verhaltens-

weisen oder auch Verhaltens-Cluster wurden von Belbin den neun in Abb. 3.23 dargestell-

ten Teamrollen zugeordnet.

Belbin unterscheidet drei Kompetenz-Gruppen und ordnet ihnen die Teamrollen zu:

Erledigen: Macher, Perfektionist, Umsetzer

Denken: Spezialist, Neuerer, Beobachter

Kommunizieren: Teamarbeiter, Koordinator und Wegbereiter

Neuerer

theoretisiert

Perfektionist

perfektioniert

Spezialist

speziﬁziert

das Detail

Teamarbeiter

unterstützt

Umsetzer

wendet an

Wegbereiter

ﬁndet neue Möglichkeiten

Koordinator

generalisiert

Macher

treibt an

Beobachter

bewertet

unparteiisch

Abb. 3.23 Belbin Teamrollen. (Belbin Deutschland e.K./Bergander 2008)

3.10

Persönliche Weiterentwicklung

339

Jede Teamrolle hat positive und negative Eigenschaften

In der Arbeit mit den Teamrollen ist es wichtig zu betonen, dass es keine „guten“ oder

„schlechten“ Teamrollen gibt. Jede Teamrolle beinhaltet wichtige positive Eigenschaften

(Stärken) für die erfolgreiche Teamarbeit. Ohne die Ideen der Neuerer kann kein Projekt

innovative Lösungen entwickeln. Ohne die Macher bleibt das Projekt in den theoretischen

Konzepten stecken und wird nicht umgesetzt. Ohne die Begeisterungsfähigkeit der Weg-

bereiter werden neue Möglichkeiten nicht erkundet oder das Stakeholder-Management

vernachlässigt.

So wie der Schatten zum Licht gehört, haben diese positiven Eigenschaften gerade

dadurch, dass sie den Durchschnitt des Teams überragen, eine negative Konsequenz und

damit eine Schwäche: Die Neuerer verlieben sich in ihre eigenen Lösungen, obwohl sie

nicht den Bedürfnissen der Kunden entsprechen. Die Macher haben die Tendenz, mit dem

Kopf durch die Wand zu rennen, andere Personen mit ihrem Vorwärtsdrang zu brüskieren

und Dinge zu tun, die sie nicht tun sollten. Die Wegbereiter reißen zwar viele Dinge an,

bringen dann aber nichts wirklich zu Ende.

Belbin Teamrollen zur Steigerung der Selbsterkenntnis

Die Basis für den persönlichen Teamrollenbericht bildet eine persönliche Selbsteinschät-

zung, die anhand eines strukturierten Fragebogens gemacht wird. Diesem werden dann

vier bis acht Fremdeinschätzungen aus dem eigenen Wirkungsfeld gegenübergestellt. Vor

allem in den Unterschieden zwischen Selbst- und Fremdwahrnehmung liegt das Entwick-

lungspotenzial jeder einzelnen Person: Oft ist es so, dass die eigenen Stärken geringge-

schätzt oder gar nicht wahrgenommen werden.

Beispiel

Wer schon seit seiner Jugend immer wieder neue Ideen hat, für den ist ein gewisses

Level an Kreativität selbstverständlich (Neuerer). Das ist auch der Fall, wenn man sich

daran gewöhnt hat, die Dinge an die Hand zu nehmen statt nur im Kreis zu reden, oder

wenn es normal ist (Macher), im Falle einer Problemstellung mal einen Benchmark mit

anderen Marktteilnehmern zu machen oder sein eigenes Netzwerk zu aktivieren, statt

selber das Rad neu erﬁnden zu wollen (Wegbereiter).

Andere Menschen können einem also zuerst einmal helfen, sich die eigenen Stärken

bewusst zu machen. Natürlich sind sie dann auch ein guter Spiegel für die Sensibilisierung

auf die Verhaltensmuster, in denen jemand irritiert oder sogar brüskiert wird.

Damit Belbin auf der persönlichen Ebene ein Gewinn ist, braucht es bei allen Beteilig-

ten gut entwickelte persönliche Kommunikationskompetenzen (Abschn. 3.9). Fremdein-

schätzungen nach Belbin sind Feedbacks. Diese können nur konstruktiv sein, wenn die

Person, die das Feedback erhält, unterscheiden kann zwischen Wirkung und Wertung. Wer

Feedback als eine Wertung der eigenen Person ansieht, für den ist dies möglicherweise be-

drohlich. Er wird versuchen, sich davor zu schützen. Wenn Feedback aber eingesetzt wird

340

Mensch

um zu erfassen, wie eine Person auf eine andere wirkt, wird die eigene, subjektive Wahr-

nehmung dafür zur Verfügung gestellt. Was die Person, welche das Feedback erhält, dann

damit tut, ist ihr überlassen.

3.10.2.2

MBTI

Basierend auf der von Carl Gustav Jung beschriebenen Entwicklungspsychologie entwi-

ckelten die beiden Frauen Isabel Myers und Katharine Briggs in den USA die Persön-

lichkeitstypologie MBTI (Myers-Briggs Type Indicator). Seit 1999 ﬁndet auch das auf

der gleichen Theorie beruhende, weiterentwickelte Testverfahren des Golden Proﬁler of

Personality (GPOP) Anwendung. Sie beide gehören heute zu den am meisten genutzten

Analyseinstrumenten, da sie in mehreren Sprachen zur Verfügung stehen und über eine

sehr große Testbasis von mehreren Millionen Auswertungen verfügen. Der Erfolg ba-

siert auch darauf, dass es auf Dimensionen aufbaut, welche wesentliche Eigenschaften

des beruﬂichen Umfeldes beschreiben (Abb. 3.24): Einstellung zur Außenwelt (introver-

tiert oder extravertiert), Herangehensweise (beurteilend oder wahrnehmend), Wahrneh-

men (analytisch oder intuitiv) und Entscheiden (analytisch oder gefühlsmäßig). Diese vier

Grunddimensionen werden jeweils mit ihren Ausprägungen beschrieben. Die daraus mög-

lichen 16 Variationen ergeben Persönlichkeitsproﬁle mit sehr unterschiedlichen Stärken

und Schwächen.

Diese Typenkombinationen ergeben 16 Persönlichkeitsfunktionen, bestehend aus den

Kombinationen der jeweiligen vier präferierten Einstellungen. So lassen sich Persönlich-

keitsproﬁle aufzeigen, welche für bestimmte Rollen, Funktionen und Aufgabenstellungen

bessere Voraussetzungen mitbringen als andere. Viele Firmen nutzen diese Erkenntnisse

bei Stellenbesetzungen und bei der Zusammenstellung von Teams.

3.10.3

Coaching

Für die Bewältigung eines Burnouts ist in Abschn. 3.5.9 ausgeführt, wie wichtig die pro-

fessionelle Begleitung ist. Eine solche Lernbegleitung kann für alle Projektbeteiligten in

speziﬁschen Situationen viel Sinn machen. Jeder Sportler hat einen Coach, welcher ihn in

seiner Weiterentwicklung unterstützt. Projektmitarbeitende sind auch Hochleistungssport-

ler, einfach im mentalen Bereich.

Das Coaching bietet eine Reﬂexionsebene, welche speziﬁsch auf die jeweiligen Funk-

tionen und Rollen des Coachee ausgerichtet ist. Die Inhalte können fokussieren auf Über-

legungen in der Planung oder Umsetzung der nächsten Arbeitsschritte, zum Verhalten in

kritischen Situationen und im Umgang mit Konﬂikten. Sinnvoll sind aber auch Reﬂexio-

nen, um Reaktionen, Verhalten und Ergebnisse von vergangenen Situationen besser zu

verstehen, zu analysieren und daraus zu lernen. Dies hilft einerseits, eigene Enttäuschun-

gen und Ängste zu verarbeiten, anderseits vor allem, zukünftige Situationen besser zu

gestalten.

3.10

Persönliche Weiterentwicklung

341

Extraversion

Sensing

Thinking

Judging

Introversion

Intuition

Feeling

Perceiving

Einstellung zur Umwelt

Einstellungen

Kontaktaufnahme

Wahrnehmung

Informationsaufnahme

Entscheidung

Informationsbewertung

Einstellung zum Handeln

Herangehensweise

Funktionen

Abb. 3.24 Dimensionen des MBTI

Entsprechenddem Modell der dreiEbenen der Zusammenarbeit (Abschn.1.5)ist

es sinnvoll, wenn der Projektleiter überprüft, ob er mit seinen Gestaltungs- und

Führungsinterventionen ...

auf der Inhaltsebene wissens- und ergebnisorientiertes Arbeiten ermög-

licht,

auf der Beziehungsebene ein Klima von Akzeptanz und Vertrauen fördert

und

auf der Organisationsebene Ordnung und günstige Strukturen gewährleis-

tet.

In einem Coaching ist darauf zu achten, den Projektleiter darin zu unterstützen, dass er

den Stand des Projektes richtig erfasst und erkennt, wo zurzeit Risiken bestehen. Daraus

entwickelt er Szenarien für die weitere Prozessgestaltung. Das Coaching eines Projekt-

leiters ist oftmals recht schwierig, da es nur schwer möglich ist, sich in der Rolle eines

Coaches im engeren Sinne zurückhaltend zu verhalten. Vielmehr braucht der Coachee

einen Gesprächspartner für die Strategieüberlegungen und Reﬂexion der bisherigen Er-

eignisse, für die Planung der nächsten Arbeitsschritte, das Konﬂiktmanagement, ebenso

wie einen Lieferanten für Methoden, einen „Frust-Abhörer“ und Rollenwächter.

342

Mensch

Diese Vielschichtigkeit stellt auch einige Anforderungen an den Coach. So sollte er

folgende Themen beherrschen:

arbeitstheoretische Ansätze wie Systems Engineering, Systemisches Denken, Simulta-

neous Engineering, Organisationsentwicklung, Veränderungsmanagement

Arbeitstechniken wie Zeitmanagement, Moderation, Krisenintervention

Besonderheiten der Dynamik von Projekten in Organisationen

Umgang mit Drucksituationen, welche die verschiedenen Interessensgruppen erzeugen

Je mehr eigene Erfahrungen der Coach mitbringen kann, desto höher wird einerseits

auch seine Akzeptanz beim Coachee sein. Andererseits ist es umso wichtiger, im Contrac-

ting zu klären, welche Beratungsleistungen der Coachee haben will: Coaching im Sinne

von Prozessberatung oder auch Expertenberatung zu Fach- und Methodenfragen.

Coaching soll freiwillig sein. Der Coachee soll das Coaching wollen und es nicht

als Zurechtweisung auffassen. Es geht nicht darum, in den Situationsschilderun-

gen Fehler schönzureden oder etwas zu beschönigen, um gut dazustehen.

Coaching ist keine Beurteilung im Sinne einer Prüfung, sondern eine Möglichkeit, mit

fremder Hilfe die Qualität der eigenen Arbeit zu prüfen, kritisch zu hinterfragen und zu

stärken. Es hilft, Risiken zu erkennen und zu qualiﬁzieren, eigene und fremde Motiva-

tionen zu verstehen, seine Wahrnehmung mit der Außensicht zu erweitern und vor allem

mögliche Alternativen zu verschiedensten Problemen, die mit der Projektleitung verbun-

den sind, zu entwickeln.

3.10.4

Intervision

Eine andere Plattform der persönlichen Weiterentwicklung bietet die Intervision. Der

Psychoanalytiker Michael Balint entwickelte eine Methode für die Fallbearbeitung un-

ter Psychoanalytikern. Die Methode fußt auf der Grundidee, dass in Problemsituationen

häuﬁg die Anteile der Anderen gut erkannt, die eigenen Beiträge zum Problem jedoch

teilweise ausgeblendet werden (Abschn. 3.9.7.1). Neutralen Beobachtern einer Situation

fallen solche Anteile nach kurzer Zeit auf. Sie können durch wertvolles kritisches Feed-

back neue Ansichten zum Problem aufzeigen und neue Lösungsansätze erkennen lassen.

Die Intervisionsmethode strukturiert die Behandlung eines Problems, das ein Gruppen-

mitglied mit nicht daran beteiligten Personen lösen will.

Michael Balint hat herausgefunden, dass es hilfreich ist, die Eindrücke der Außenste-

henden zu diskutieren, ohne dass der Fallgeber sofort dazu Stellung nimmt. So hat eine

Balint-Sitzung eine klare Struktur:

3.10

Persönliche Weiterentwicklung

343

1. Der Fallgeber schildert sein Problem

Die Gruppe hört zu und unterbricht nicht. Die Zuhörenden notieren, was ihnen bei der

Schilderung in den Sinn kommt, was sie empﬁnden und wie sie den Fallgeber erleben

(unsicher, nervös, arrogant, ausschweifend usw.).

2. Die Gruppe stellt Verständnisfragen

Die Gruppe stellt nur Verständnisfragen, keine Fragen, die eine Vermutung, Hypothe-

se, Interpretation usw. enthalten. Der Moderator achtet darauf, dass nur das Verständnis

verbessert wird und lässt die Fragerunde so lange laufen, bis er den Eindruck hat, dass

die Gruppe für die nächste Phase genügend Informationen hat. Diese Sequenz kann

unterschiedlich lange dauern.

3. Die Zuhörer schildern ihre Hypothesen

Erlaubt sind Gedanken, Eindrücke, Vermutungen, Ursachen usw. jedoch noch keine

Lösungen. Dabei dürfen die Zuhörer ihren Phantasien freien Lauf lassen. Jemand

schreibt die Rückmeldungen der Gruppe stichwortartig auf einen Flip auf. Der Fall-

geber ist von der Gruppe abgewendet, hört jedoch zu, ohne – auch nur nonverbal –

Stellung zu nehmen. Er darf sich nicht einschalten, kann sich aber seine Gedanken,

Einfälle usw. notieren.

4. Der Fallgeber nennt die Treffer

Er geht die Auﬂistung durch und sagt, was für ihn zutrifft und warum, bzw. was falsch

ist oder in welchem Grad es für ihn zutrifft. Die „Falschmeldungen“ streicht er durch.

Dabei ist seine subjektive Sicht richtig! Während der Moderator in den ersten drei

Schritten streng auf die Einhaltung der Sprechregeln achtet, kann er in dieser Phase

mehr Diskussionen zulassen.

5. Die Gruppe erarbeitet Lösungsvorschläge

Der Fallgeber oder ein Teilnehmer notiert und visualisiert die Vorschläge. Nötigenfalls

wird die Lösung in einem Rollenspiel simuliert.

6. Die Schlussrunde

Diese gibt dem Fallgeber die Gelegenheit, der Gruppe mitzuteilen, welche Erkennt-

nisse er aus der Sitzung mitnimmt. Die übrigen Gruppenmitglieder überlegen, was sie

für sich gelernt haben. Je stärker sich der Fallgeber persönlich exponiert hat, desto

wichtiger ist es, dass die restlichen Gruppenmitglieder jetzt etwas über sich sagen.

3.10.5

Upside- oder Downside-Strategie?

Verändern, Neubewerten oder Verdrängen: Nach welchen Kriterien können wir unsere

persönliche Weiterentwicklung ausrichten?

Die Upside- resp. Downside-Strategie bietet hier einen wirkungsvollen Ansatz (Dobelli

2017b). Unter Upside versteht man alle positiven Eigenschaften, die über eine Maßnahme

oder Veränderung erreicht werden sollen. In der Downside-Strategie geht es genau um das

Gegenteil.

344

Mensch

Beispiel

Upside: Was motiviert mich? Wie kann ich mehr Sinnerfüllung erfahren? Oder ge-

nerell: Was fördert ein besseres Leben?

Downside: Was demotiviert mich? Wann fühle ich mich gestresst? Und warum?

Vor welchen sinnlosen Aufgaben möchte ich mich schützen? Oder generell: Was

verhindert ein besseres Leben?

Vielfach ist die Downside-Strategie viel effektiver: Das, was uns Mühe macht, als sinn-

los erscheint oder eben demotiviert, ist konkret greifbar. Wir erfahren dies tagtäglich. Sich

hingegen zu fragen, welches denn ein passender Job sein könnte, was mich zufriedener

machen würde, ist viel schwieriger. Die Anstrengung, immer wieder aus der „Downside“-

in die „Upside“-Perspektive zu wechseln, lohnt sich in jedem Fall.

Literatur

Amrein, M. (2015). In unserem Ohr steckt eine Wasserwaage. In: Zürich: NZZaS, 13.09.2015.

Antons K. (1992). Praxis der Gruppendynamik. Göttingen, Hogrefe Verlag.

Ballreich, R., & Hüther, G. (2009). Du gehst mir auf die Nerven! Neurobiologische Aspekte der

Konﬂiktberatung. Stuttgart: Concadora Verlag.

Bamberger, G. (2005). Lösungsorientierte Beratung. Weinheim, Basel: Beltz Verlag.

Biswas, C. (2015). Hier entsteht die Zukunft. Zürich: NZZaS, 20.12.2015.

Brand, Ch. (2017). Tausendmal gescheitert. Zürich: NZZ, 4.06.2017.

Covey, S. (2014). Der Weg zum Wesentlichen. Frankfurt/New York: Campus Verlag.

Csikszentmihalyi, M. (2004). Flow, the secret to happiness. Abgerufen am 23. Januar 2018 von

TED: ted.com.

Dobelli, R. (2017a). Die Kunst des guten Lebens. München: Piper Verlag.

Dobelli, R. (2017b). Ergründen Sie Ihre Downside. Zürich: NZZ, 9.09.2017.

Donzé R., & Pﬁster, F. (2015). Leben heißt spüren. Zürich: NZZaS, 11.10.2015, S. 53 ff.

Drath, K. (2014). Resilienz in der Unternehmensführung. Freiburg: Haufe-Lexware.

Esch, T. (2014). Die Neurobiologie des Glücks. Stuttgart: Georg Thieme Verlag.

Gruhl, M. (2008). Die Strategie der Stehaufmännchen. Resilienz – so nutzen Sie Ihre inneren Kräfte.

Freiburg im Breisgau: Herder Verlag.

Hirschhausen, E. (2010). Glück kommt selten allein. Reinbek bei Hamburg: Rowohlt Verlag.

Hirschhausen, E. (2016). Wunder wirken Wunder. Reinbek bei Hamburg: Rowohlt Verlag.

Hüther, G. (2016, 2001, 12. Auﬂage). Bedienungsanleitung für ein menschliches Gehirn. Göttingen:

Vandenhoeck & Ruprecht Verlag.

Hüther, G. (2016, 1997, 13. Auﬂage). Biologie der Angst. Wie aus Stress Gefühle werden. Göttin-

gen: Vandenhoeck & Ruprecht Verlag.

Largo, R. (2017): Das passende Leben. Frankfurt am Main: Fischer Verlag.

Lippmann, E. (2013). Coaching. Heidelberg: Springer Verlag.

Müller, G (2015). Innovation wird von unten erzeugt. Zürich: NZZ, 5.06.2015.

Pﬂäging, N. (2015). Organisation für Komplexität. München: Redline Verlag.

Rager, G. und von Brück, M. (2012). Grundzüge einer modernen Anthropologie. Göttingen: Van-

denhoek & Ruprecht.

Literatur

345

Schmid, W (2010). Auf der Suche nach Glück. Zürich, NZZ Format.

Schneider, S. (2003). Trau, Schau, Wem. Input DRS 3.

Schulz von Thun, F., et. al. (2005). Miteinander reden: Kommunikation für Führungskräfte. Reinbek

bei Hamburg: Rowohlt Verlag.

Sprenger, R. (2014). Mythos Motivation. Frankfurt/New York: Campus Verlag.

Stadelmann, U. (2017). Warum unserem Hirn teurer Wein besser schmeckt. Zürich: NZZ,

15.11.2017, S. 25.

Steiger, T. und Lippmann, E. (Hrsg.), (2008. 3. Auﬂ., Bd. I). Handbuch angewandte Psychologie für

Führungskräfte. Heidelberg: Springer Medizin Verlag.

Walser C. und Wild P. (2002). Men’s Spirit. Spiritualität für Männer. Freiburg: Herder Verlag.

Team

Die Komplexität der Projektziele bedingt immer eine interdisziplinäre Zusammenarbeit.

Damit Zusammenarbeit gelingt, braucht jedes Team – so wie eine Fußballmannschaft –

eine Aufstellung. Diese erfolgt im Projektmanagement über die Rollenklärung.

Der Mensch als nicht-triviales System (Abschn. 1.6.2) muss in diesem Prozess einen

Teil seiner Selbststeuerung aufgeben und seine eigenen Interessen und Überzeugungen

den gemeinschaftlichen Zielen unterordnen können. Deshalb braucht ein Team immer

auch Führung, im agilen wie auch im klassischen Ansatz. Führung wiederum ist ohne

Macht nicht möglich.

Dieses Kapitel beschreibt zuerst die grundsätzlichen Aspekte von Zusammenarbeit und

Führung, danach die Dynamik, welche sich in Teams während der Projektarbeit entfalten

kann. Im Zentrum stehen die beiden wichtigen Kompetenzbereiche Verhandlungsführung

sowie Konﬂiktmanagement und Krisen. Der Umgang mit Veränderungen und Widerstand

schließt das Kapitel ab. Die Themenbereiche sind untergliedert nach ihrer Relevanz für

den agilen und den klassischen Ansatz.

4.1

Zusammenarbeit und Führung

4.1.1

Zusammenarbeit im Projekt

In Projekten sind kreative Lösungen für anstehende Probleme mittlerer bis hoher Komple-

xität zu entwickeln. Projektteams kreieren neue Ideen, formulieren Visionen und Ziele. Sie

ermöglichen während einer begrenzten Zeitdauer eine interdisziplinäre Zusammenarbeit

von Experten aus unterschiedlichsten Fachbereichen. Die Hierarchie der Stammorgani-

sation bezweckt genau das Gegenteil: Dort werden die jeweiligen Experten nach ihren

Fachbereichen gebündelt.

Damit bekommt ein weiterer wichtiger Faktor in der Projektarbeit Gewicht: Es geht

darum, eine Form der Zusammenarbeit und einen Zusammenhalt zu entwickeln, damit

347

J. Kuster et al., Handbuch Projektmanagement, https://doi.org/10.1007/978-3-662-57878-0_4

348

Team

das interdisziplinäre Team auf die gemeinsamen Ziele hinarbeiten kann. Diese Form der

Zusammenarbeit orientiert sich am agilen oder klassischen Ansatz oder an einem Mix

(Hybrid), wie in Kap. 2 ausgeführt. Die Form der Zusammenarbeit darf aber nie beliebig

sein.

In Bezug auf die Zusammenarbeit von Projektteams sind die folgenden Aspekte we-

sentlich:

Projektgruppen verfügen über wertvolle Leistungsvorteile und lösen komplexe

Aufgabenstellungen besser

Komplexe Aufgabenstellungen beinhalten einen hohen Anteil an Unbekanntem. Um Lö-

sungen zu erarbeiten, müssen in Projektteams verschiedenste Fachspezialisten und Träger

unterschiedlichster Funktionen zusammenwirken. Interdisziplinär und organisationsüber-

greifend zusammengesetzte Projektteams entwickeln dank ihrer Wissensvielfalt und des

großen Informations- und Erfahrungsumfangs einen starken Leistungsvorteil, wie er sonst

nirgends in der Organisation vorhanden ist. Durch direkte Gespräche im Team werden

die Kommunikationshemmnisse der Hierarchie abgebaut. Das Zusammenwirken aller Be-

teiligten unterstützt den Problemlösungsprozess. Bei optimalem Leistungsvermögen und

Engagement bringt das Team in kurzer Zeit Lösungen zustande, die auf hoher fachlicher

Kompetenz basieren und sich durch breite Akzeptanz auszeichnen.

Konsensfähigkeit und Akzeptanz sind bei Teamlösungen größer

Projekte ﬁnden oft in einem Umfeld voller gegensätzlicher Interessen und Ansprüche

statt. Für die Entwicklung gemeinsamer Stoßkraft und die Umsetzung der erarbeiteten

Lösungen ist es von entscheidender Bedeutung, dass sich die Interessenvertreter der ver-

schiedenen Organisationseinheiten mit den Projektergebnissen identiﬁzieren.

Mit dem gemeinsamen Entwicklungsprozess steigen die Lernerfahrung und das Wissen

um die Grenzen der organisatorischen, ﬁnanziellen oder personellen Machbarkeit bei den

Teammitgliedern und den verschiedenen Stellen in der Organisation. Die Bereitschaft,

einen Konsens zu ﬁnden und die im Projektteam erarbeiteten Lösungen zu akzeptieren,

nimmt zu. Außerhalb des Projektteams ﬁndet diese Entwicklung jedoch nur dann statt,

wenn es den Projektteammitgliedern zumindest teilweise gelingt, den Lösungsprozess in

ihre Stammorganisation zurückzutragen.

Der Aufbruch zu neuen Ufern fällt gemeinsam leichter

Neuland betreten heißt, von Gewohntem Abschied zu nehmen, was immer auch mit Un-

sicherheit und Angst verbunden ist. Aus der gemeinsamen Tat wächst die Stärke, werden

die Beteiligten mutiger und risikofreudiger. Dies kann dazu führen, dass bekannte Wege

verlassen und wirklich innovative und ungewohnte Lösungsmöglichkeiten ausgedacht und

ausprobiert werden.

Die Begeisterung eines Teams kann den Einzelnen über seine Grenzen hinauswachsen

lassen und zu Spitzenleistungen motivieren. Durch das gegenseitige Anspornen, Heraus-

4.1

Zusammenarbeit und Führung

349

fordern, aber auch Anregen und Unterstützen, werden in einem gut funktionierenden Team

Kreativität, Originalität und Innovation in erstaunlichem Ausmaß möglich.

4.1.2

Führung – was ist das?

Jedes Team braucht Führung, egal, ob es nach dem agilen oder klassischen Ansatz arbei-

tet. Das Wort Führung wird von den beteiligten Menschen oft recht zwiespältig erlebt.

Die einen denken dabei an Verantwortung und Herausforderung. Andere denken eher an

Herrschaft und Befehlsgewalt und damit an Unterdrückung und Mittel, um eigene Ansprü-

che durchzusetzen. Tatsächlich weist das Wort „Führung“ auf Macht und Einﬂussnahme

auf andere hin. Wer Führungskompetenz hat, übt Macht über Menschen oder Menschen-

gruppen aus. Die Art und Weise dieser Machtausübung ist aber letztlich entscheidend,

von welcher Qualität die Führungsarbeit ist bzw. ob sich damit auch ein Führungserfolg

einstellt.

I Es gibt eine große Vielfalt an Deﬁnitionen von Führung, wie die folgenden Beispiele

belegen:

Führung heißt, Menschen von einer Idee zu überzeugen und sie zu befähigen, diese

Überzeugung in aktives Handeln zu transformieren.

Führung spielt sich immer in Beziehungen ab. Führende und Geführte verhalten sich

nach je eigenen, subjektiven Konzepten, die zudem gruppenspeziﬁsch und situations-

abhängig sind.

Führung ist die zielorientierte, soziale Einﬂussnahme zur Erfüllung gemeinsamer Auf-

gaben in oder mit einer strukturierten Arbeitssituation.

Führung heißt ständiges Problemlösen in sozialen Systemen.

Führung ist das Erkennen, Gestalten und Steuern von zwischenmenschlichen Prozes-

sen und kann in die zwei Teile Führungstätigkeiten und Führungsverhalten aufgeteilt

werden.

Für das klassische Projektmanagement orientieren wir uns an folgender Deﬁnition

Tab. 4.1.

Tab. 4.1 Deﬁnition von Führung

Führung bedeutet

die ...

– Verantwortungsübernahme für die Erfüllung einer Aufgabe oder die

Erreichung eines Zieles ...

– ... welche die Zusammenarbeit einer Gruppe von Menschen erfordert

Führung erfordert

die ...

– Ausstattung der Führungsperson oder einer Gruppe mit besonderen

Rechten der Einﬂussnahme und (Gestaltungs-)Macht

– bewusste Wahrnehmung dieser Macht durch die Führungsperson oder

Gruppe

350

Team

Diese Deﬁnition offenbart, dass Führung nur dann benötigt wird, wenn mehrere Perso-

nen ein gemeinsames (Sach-)Ziel erreichen sollen.

Auch selbstgesteuerte Teams, wie wir sie im agilen Projektmanagement kennen, brau-

chen Führung. In diesem Kontext spricht man von kollegialer Führung:

Kollegiale Führung ist die auf viele Kollegen und Kolleginnen dynamisch und dezentral

verteilte Führungsarbeit anstelle von zentralisierter Führung durch einige exklusive Füh-

rungskräfte (Oestereich und Schröder 2017, S. VII).

Im klassischen Führungsverständnis und damit auch im klassischen Projektmanage-

ment werden speziﬁsche Personen und Organe mit Führungskompetenzen und Führungs-

verantwortung ausgestattet. In der Selbststeuerung des agilen Projektmanagements fällt

die Führungskraft weg. Das Team als Ganzes übernimmt die Führungsarbeit. Diese ist

allerdings wiederum eingebettet in ein System mit speziﬁschen weiteren Führungskom-

petenzen, wie in Abschn. 4.1.12 ausgeführt wird.

4.1.3

Macht und Autorität

4.1.3.1

Ermächtigung und Bemächtigung: Macht basiert auf Beziehung

Der Mensch ist grundsätzlich ein selbstgesteuertes, „nicht-triviales System“. Sein Fühlen,

Denken und Handeln sind immer das Resultat von inneren, sehr komplexen Prozessen.

Immer dann, wenn das Handeln oder die Einstellung eines Menschen nicht seiner natür-

lichen, inneren Entwicklung entspricht und er möglicherweise gegen die eigene Neigung

oder Absicht handelt, wirkt das Phänomen der Macht (Zirkler 2008, S. 383). Macht ist we-

der gut noch schlecht. Macht ist Grundvoraussetzung, um gemeinsame Ziele zu erreichen.

Auch in Bezug auf Macht werden mehrere Deﬁnitionen verwendet:

Macht ist die Fähigkeit, organisatorische Ergebnisse zu bewirken oder zu beeinﬂussen (Spi-

sak und Della Picca 2017).

Macht ist die Fähigkeit von Personen oder Gruppen, das Verhalten von anderen Individuen

und Gruppen in ihrem Sinne zu beeinﬂussen. Machtmissbrauch entmächtigt andere Men-

schen. Guter Machtgebrauch ermächtigt andere Menschen (Beat Hänni & Felix Marti).

Macht ﬁndet immer nur in Beziehungen statt. Damit der Mensch etwas tut, was an-

dere von ihm verlangen, muss er seine natürliche Anlage zur Selbststeuerung aufgeben.

Wenn plötzlich eine unbekannte Person an Ihrem Arbeitsplatz auftaucht und von Ihnen

verlangt, einen Bericht über den aktuellen Stand Ihres Projektes auszuhändigen, werden

Sie das kaum tun. Sie würden zuerst prüfen, wer diese Person ist und was diese dazu

legitimiert, diese Informationen einzusehen. Wenn dieselbe Bitte jedoch von Ihrem Vor-

gesetzten kommt, werden Sie seiner Aufforderung umgehend nachkommen. Eine Person,

die eine Erwartung von jemand anderem erfüllt, muss also immer erst diese andere Person

dazu ermächtigen, auf das persönliche Verhalten Einﬂuss zu nehmen.

4.1

Zusammenarbeit und Führung

351

In Führungsaufgaben braucht es neben der Ermächtigung aber auch noch die Bemäch-

tigung. Der Projektleiter oder der Product Owner müssen auch die Macht einfordern und

wahrnehmen, die ihre Rolle von ihnen fordert.

In der oben dargelegten Deﬁnition ist Führung ein Zusammenspiel zwischen Ver-

antwortungsüberahme und dem Wahrnehmen von Gestaltungsmacht. Die Führungskraft

muss die Verantwortung übernehmen für die gemeinsamen Ziele. Sie muss sich der Füh-

rungsaufgabe (z. B. als Projektleiter) bemächtigen. Wirkungsvoll wird ein Projektleiter

aber erst, wenn er mit Gestaltungsmacht ausgestattet wird, um über Projektauftrag, Pro-

jektorganisation, -Struktur und -Methoden (mit-)entscheiden zu können. Damit er das tun

kann, müssen alle in das Projekt involvierten Personen und Gremien den Projektleiter in

seiner Rolle ermächtigen. Der Auftraggeber muss dem Projektleiter Entscheidungs-

kompetenzen abtreten in den inhaltlichen Sachfragen, aber auch in Bezug auf die

Beziehungs- und Organisationsebene. Die einzelnen Teammitglieder müssen sich auf

das gemeinsame Ziel ausrichten und damit bewusst den eigenen Willen und die persönli-

chen Überzeugungen den Gruppenzielen unterordnen.

Macht basiert immer auf dem Zusammenspiel zwischen Bemächtigung und Ermächti-

gung. Der selbstbestimmte Mensch steht über Kommunikation mit anderen Personen, wel-

che Erwartungen, Anweisungen oder Anforderungen formulieren können, in Beziehung.

Schließlich ist es aber immer noch der Mensch, an den diese Anforderungen kommuni-

ziert werden, welcher aktiv einer anderen Person diese Gestaltungsmacht auf das eigene

Handeln zuordnen muss. In irgendeinem Sinne braucht es also in der Führung immer Be-

mächtigung einer Person, die die leitende Funktion übernimmt, und Ermächtigung von

der Person, auf die diese Gestaltungsmacht ausgeübt wird.

Auch das agile Projektmanagement braucht ein intaktes Machtsystem. Ist der Pro-

duct Owner vom Auftraggeber nicht ermächtigt, die inhaltlichen Entscheide bei den

Sprint Reviews zu fällen, kann er seine Aufgabe nicht erfüllen. Der Product Owner muss

sich dann aber auch dadurch bemächtigen, dass er die Entscheide wirklich fällt und

nicht bei Unsicherheiten den Entscheid an jemand anderes delegiert. Und auch der Scrum

Master braucht Ermächtigung für seine Rolle: Das Team muss ihn dazu ermächtigen,

Störungen zu bearbeiten oder die Moderation der Sprint Retrospektive wahrzunehmen.

Die Stammorganisation muss den Scrum Master dazu ermächtigen, alle Widerstände und

Schwierigkeiten, die das Team in seiner Arbeit behindern, schnell zu bearbeiten. Span-

nend und auch anspruchsvoll ist das Spiel zwischen Ermächtigung und Bemächtigung im

Team selber. Hier gibt es keine klaren Zuordnungen. Vielmehr geht es darum, die Balance

zwischen den beiden Polen immer wieder neu herzustellen.

4.1.3.2

Klassische Quellen der Macht

Beim Wort Macht denken viele Menschen an autoritäre Macht. Diese ist entsprechend

negativ konnotiert. In Tab. 4.2 werden die klassischen Machtquellen aufgeführt, die ur-

sprünglich von French und Raven (1959) entwickelt wurden und immer noch Gültigkeit

haben (Spisak und Della Picca 2017, S. 156 f.)

352

Team

Tab. 4.2 Klassische Quellen der Macht

Macht

Basiert auf ...

Legitime Macht, Posi-

tionsmacht

– Position oder Funktion in der Organisation

– Arbeitsvertrag, Projektauftrag

Macht durch Belohnung

Fähigkeit, anderen Personen etwas ...

– zu geben, das sie begehren, oder

– wegzunehmen, das sie nicht begehren

Macht durch Bestrafung

Fähigkeit, anderen Personen ...

– Belohnungen vorzuenthalten

– Sanktionen auszusprechen

Informationsmacht

– Informationsvorsprung gegenüber anderen Personen

– Zugehörigkeit zu Führungsorganen

Macht durch Identiﬁkati-

on, Vorbild

– attraktiven Persönlichkeitsmerkmalen oder Ressourcen einer Person

– Gefühl von Verbundenheit und Loyalität

Wissen und Expertentum – Qualiﬁkation und Expertise in einem speziﬁschen Bereich

– Diplomen, (Projektmanagement-)Zertiﬁzierungen

Positionsmacht, Macht durch Belohnung und Bestrafung sowie die Informationsmacht

sind weitgehend einer Person im Rahmen der Position, die sie einnimmt, durch die Organi-

sation (Hierarchie) zugewiesen. Dafür wird der Begriff „Institutionelle Macht“ verwen-

det. Ein Abteilungsleiter kann über Anstellungen entscheiden, Löhne und Boni zumindest

mitbeeinﬂussen oder durch seine fachliche Weisungskompetenz auch entscheiden, wer

die attraktiven Projekte übernimmt und wer eher die Fleißarbeit verrichtet. Projektverant-

wortliche haben in ihrer informellen Führungsaufgabe oft keinen Zugang zu dieser Macht.

Aus diesem Grund ist die Rolle des Auftraggebers im klassischen Projektmanagement so

wichtig. Als Repräsentant der Linienhierarchie hat er Zugang zu diesen Machtquellen.

Stellt der Auftraggeber diese oder Teile davon dem Projektleiter zur Verfügung, ﬁndet

eine Ermächtigung statt, die auf geliehener Macht basiert (siehe unten).

Bei der Macht durch Identiﬁkation und Vorbild sieht dies anders aus. Diese gehört

vielmehr dem Individuum selber als persönliche Macht. Zu einem Vorbild wird, wer tut,

was er sagt („walk the talk“). Zum Expertentum gehören das Interesse und die ständige

Weiterbildung im entsprechenden Fachbereich.

4.1.3.3

Weitere Machtquellen im Projektmanagement

In Organisationen bestehen noch weitere Machtquellen, welche wesentlich sind für Pro-

jektorganisationen (Tab. 4.3). Je besser Projektleiter oder Product Owner diese für sich

erschließen, umso wirkungsvoller werden sie in ihren Rollen sein.

Mehrere dieser Machtquellen haben den Ursprung in der institutionellen Macht: Verfü-

gung über Ressourcen, Entscheidungskompetenzen, Schnittstellenmanagement und Ver-

fügung über Technologie sind zu einem wesentlichen Teil an die Position gebunden,

welche eine Person in der Hierarchie einnimmt.

4.1

Zusammenarbeit und Führung

353

Tab. 4.3 Machtquellen im Projektmanagement

Macht

Basiert auf ...

Verfügung über Ressourcen

– fachlicher Weisungsbefugnis und Direktunterstellungen

– Budgetkompetenzen

Entscheidungsmacht

– Position und Projektrolle (auch in Verbindung mit Aufgabe-

Kompetenz-Verantwortung oder RACI)

– Anbindung des Projektes an die Stammorganisation (in der

Projektkoordination bleiben diese Kompetenzen bei den Lini-

envorgesetzten)

Schnittstellenmanagement

– Weisungsbefugnis über eine Geschäftseinheit hinaus

– Z. B. der Verkaufsleiter, der eine Forderung eines Kunden vertritt

Verfügung über

Technologie

– Beherrschen von Schlüsseltechnologien wie Informations- und

Kommunikationstechnologie (ICT) im Zeitalter der Digitalisie-

rung

Allianzen und informelle

Netzwerke

– informeller Beziehungspﬂege, Teilnahme an Social Events

– Vernetzung in sozialen Medien wie Xing oder LinkedIn

Umgang mit Komplexität

und Unsicherheiten

– Persönliche Resilienz

– Selbstmanagement, Selbstreﬂexionsfähigkeit

Geliehene Macht

– Macht, die durch Auftraggeber und Linienvorgesetzte an die

Projektverantwortlichen delegiert wird

Abgeleitet von: Spisak und Della Picca 2017, S. 158 f.

Die informellen Netzwerke und der Umgang mit Komplexität und Unsicherheit sind

Errungenschaften des Individuums selber.

4.1.3.4

Projekte benötigen immer auch geliehene Macht

Im Bereich der persönlichen Macht sind Projektverantwortliche selber dafür zuständig,

sich diese Machtquellen zu erschließen und zu pﬂegen. Damit in Organisationen Ergeb-

nisse erzielt werden können, brauchen Projektverantwortliche immer auch Zugang zu

institutionellen Machtquellen. Deshalb hat in der Projektarbeit die geliehene Macht ei-

ne Sonderrolle inne. Wer Zugang zu Macht besitzt – ob institutionell oder persönlich –,

kann diese auch anderen Menschen leihen. Und das ist die Crux vieler Projektverantwort-

licher: Sie haben in ihrer Position in der Linienorganisation (Abschn. 4.1.9) oft nur wenig

Zugang zu institutioneller Macht. Ob klassisch oder agil, Projektorganisationen als Gan-

zes und die einzelnen Projektverantwortlichen im Speziellen können nur erfolgreich sein,

wenn ihnen aus der Linienorganisation Macht und die damit verbundenen Kompetenzen

geliehen werden. Der Unterschied in den beiden Ansätzen liegt darin, wem welche Macht

geliehen wird.

Die klassische Projektorganisation sieht vor, dass die Macht zwischen Projektleiter

und Auftraggeber aufgeteilt wird. Der Auftraggeber ist idealtypisch der Repräsentant

der Linienhierarchie. Mit seiner Positionsmacht und der damit verbundenen Entschei-

dungsmacht ist er der Machtträger in der Projektorganisation. Dieser ermächtigt den

Projektleiter für die Aufgaben in Bezug auf seine Prozesskompetenz.

354

Team

Die Praxis zeigt, dass v. a. in der Projektkoordination (Abschn. 2.3.9.8) die Linienvor-

gesetzten die wesentliche Machtposition im Projekt innehaben. Damit ist nicht nur die

Projektleitung auf eine Koordinationsaufgabe reduziert. Oft ist es dann auch so, dass der

Auftraggeber gegenüber den Linienvorgesetzten – die über die Ressourcenallokation in

das Projekt entscheiden – ebenfalls keine Weisungsbefugnis hat. Diesen speziﬁschen Rah-

menbedingungen in der Projektkoordination werden die Grundsätze der lateralen Führung

(Abschn. 4.1.13.3) am besten gerecht.

In der Matrix-Projektorganisation werden die Entscheidungskompetenzen dem Pro-

jektleiter im Rahmen seiner fachlichen Führungsverantwortung zugeordnet. Die stärkste

Ermächtigung erfährt ein Projektleiter in der reinen Projektorganisation.

Ohne die Delegation von Entscheidungsmacht in die Projektorganisation kann das

agile Projektmanagement grundsätzlich nicht funktionieren. Der Product Owner kann sei-

ne Steueraufgabe auf der inhaltlichen Ebene nur mit weitreichender Entscheidungsmacht

wahrnehmen. Auch die Selbststeuerung des Teams kann nur dann funktionieren, wenn die

Entscheidungen in Bezug auf die Anforderungen, die in einem Sprint umgesetzt werden,

autonom getroffen werden können.

Geliehene Macht basiert auf Vertrauen

Die geliehene Macht hat aber noch eine sehr menschliche Achillesferse. Wie steht es mit

Ihnen? Leihen Sie anderen Menschen immer großzügig persönliche oder institutionelle

Macht, die Ihnen zur Verfügung steht? Geben Sie Ihre Expertise und Ihr Wissen in Ihrem

Fachgebiet offen und uneingeschränkt weiter? Delegieren Sie einfach so Entscheidungs-

kompetenzen und Budgetverantwortung? Wahrscheinlich nicht, denn Sie wissen, dass Sie

durch diese Maßnahme Ihren Einﬂuss verlieren können oder für Fehler von anderen ge-

radestehen müssen. Sie werden nur dann einer anderen Person Macht leihen, wenn Sie zu

dieser Person genügend Vertrauen haben, siehe Abschn. 3.3.7.

4.1.3.5

Machtquellen: Zwischen Person und Institution

Abb. 4.1 fasst die relevanten Machtquellen von Projektverantwortlichen zusammen und

setzt sie in Bezug zu ihrer Herkunft. Vorbildfunktion, Allianzen und Netzwerke oder Ex-

pertentum hat das Individuum selber inne. Die daraus abgeleitete Macht kann jede Person

zu einem großen Teil in Eigenverantwortung pﬂegen und ausbauen. Belohnung oder Be-

strafung oder die Verfügungsgewalt über Ressourcen ist jedoch zu weiten Teilen abhängig

von der Ermächtigung der Institution und damit von der Position einer Person. In der

Mitte der beiden Polaritäten Person und Institution werden Entscheidungskompetenzen

angesiedelt wie die über Technologie oder das Schnittstellenmanagement. Auch die gelie-

hene Macht liegt zwischen Institution und Person.

4.1

Zusammenarbeit und Führung

355

• Vorbild

• Allianz und

informelle

Netzwerke

• Umgang mit

Komplexität/

Unsicherheit

• Wissen und

Expertentum

• Technologie

• Entscheidungs-

kompetenz

• Schnittstellen-

Management

• Geliehene Macht

• Position

• Belohnung und

Bestrafung

• Information

• Verfügen über

Ressourcen

Institutionell

Persönlich

Bemächtigung

Ermächtigung

Abb. 4.1 Machtquellen im Projekt

4.1.3.6

Autorität

Wo natürliche Autorität besteht, braucht es kein Machtgehabe (Hannah Arendt).

In Anlehnung an die Publizistin und Philosophin Hannah Arendt liegt der Unterschied

zwischen Macht und Autorität darin, dass Autorität einer Person aufgrund ihrer persön-

lichen Eigenschaften oder ihrer Rolle in der Organisation zukommt. Die Autorität wird

allerdings nur so lange zugesprochen, wie sie fraglos respektiert wird.

Autorität wird beschrieben als eine Basis für die Standhaftigkeit und die Einﬂusskraft

einer Führungsperson (Spisak und Della Picca 2017, S. 9). Die Autorität setzt sich nach

dieser Darstellung aus drei Einﬂussfaktoren zusammen:

Persönliche Autorität

Fachliche Autorität (Expertenautorität)

Formale Autorität (auf Hierarchie gegründete Autorität)

Wir Autoren betrachten Autorität – unter Berücksichtigung der Ausführungen zur

Macht – als eine Konsequenz von Macht. Wer Zugang hat zu den oben ausgeführten

356

Team

persönlichen und institutionellen Machtquellen, speist dadurch auch einen der drei Ein-

ﬂussfaktoren der Autorität.

Beispiel

Es ist auch möglich, dass Führungspersonen Zugriff auf die oben aufgeführten Macht-

quellen haben, aber durch ihr persönliches Verhalten in ihren Rollen nicht respektiert

werden. Damit wird ihnen die Autorität nicht zugesprochen.

4.1.4

Anbindung der Projektorganisation an die Stammorganisation

Einen wesentlichen Einﬂuss auf die an das Projekt delegierte Macht hat die Art und Wei-

se, wie ein temporäres Projekt an die führende Stammorganisation angebunden wird. In

Abschn. 2.3.9.8 sind die drei gängigen Formen beschrieben: Koordination, Matrix und

reine Projektorganisation.

In der Koordinationsform besitzt der Projektleiter keinerlei Weisungsbefugnisse. Da-

mit wird ihm von der Organisation auch keine Gestaltungsmacht übertragen. Er fungiert

nur als Koordinator, ist verantwortlich für den sachlichen und terminlichen Ablauf und die

Informationsﬂüsse. Die Führungsverantwortung und die Entscheidungskompetenz liegen

bei den Linienvorgesetzten.

In der Matrixform werden Mitarbeiter der Stammorganisation zu einem gewissen Pro-

zentsatz für das Projekt freigestellt. Hier wird nun effektiv Gestaltungsmacht an das Pro-

jekt delegiert. Im Rahmen dieser Freistellung (z. B. 50 % Projektarbeit) wird die fachliche

Weisungsbefugnis für diese Kapazität an den Projektleiter übertragen. Der Linienvorge-

setzte behält die fachliche Weisungsbefugnis für die verbleibenden 50 % Kapazität des

Mitarbeiters. Ebenfalls verbleibt die disziplinarische Kompetenz beim Linienvorgesetz-

ten.

In der reinen Projektorganisation werden die Mitarbeiter aus der Linienorganisa-

tion herausgelöst. Die Rollen und Gremien werden dadurch mit allen disziplinarischen

wie auch fachlichen Führungskompetenzen ausgestattet. Durch diese Anbindung wird am

meisten Macht aus der Stammorganisation in die Projektorganisation transferiert.

Viele Organisationen sind ofﬁziell in einer Matrix organisiert. Im Alltag ist es dann

aber oft so, dass die Linienvorgesetzten die Kapazitäten kontrollieren und gegenüber den

Projektleitern die Entscheide fällen, wer wann in welchem Projekt arbeitet. In diesen Fäl-

len handelt es sich tatsächlich nur um eine Projektkoordination.

Das Modell der Projektkoordination bedeutet im klassischen Ansatz, dass der „Projekt-

leiter“ praktisch keine Ermächtigung aus der Stammorganisation erfährt. Für die Zuteilung

der für ihn arbeitenden Projektmitglieder ist er von den Linienvorgesetzten abhängig.

Meist nehmen diese auch einen starken Einﬂuss auf die inhaltlichen Entscheide.

Ist in der Projektkoordination ein agiles Projektmanagement überhaupt möglich? Ko-

ordination eignet sich nicht für agil. Die Rollendeﬁnitionen von Product Owner, Team

und Scrum Master implizieren eine hohe Verfügbarkeit der Personen in agilen Projekten.

4.1

Zusammenarbeit und Führung

357

Vor allem die Mitglieder des Teams benötigen mindestens eine Arbeitskapazität von 50 %

für das Projekt, damit die Stabilität im Team erreicht wird, der notwendige Fokus auf die

Aufgaben gerichtet wird und vor allem auch, damit sich die Selbststeuerung entwickeln

kann.

Lässt das klassische Projektmanagement die drei Integrationsformen in die Stammor-

ganisation zu, limitieren sich diese im agilen Projektmanagement auf die Matrix- und die

reine Projektorganisation.

4.1.5

Aufgabe-Kompetenz-Verantwortung (A-K-V)

Die Überlegungen zum Thema Macht werden im Kongruenzprinzip von Aufgaben, Kom-

petenzen und Verantwortung (A-K-V) zusammengefasst: Jedes Projektorgan muss für die

Aufgaben, die an dieses gestellt werden, auch die entsprechende Verantwortung überneh-

men können. Das ist meistens nicht das Problem, die Projektverantwortlichen sind sich

ihrer Verantwortung sehr bewusst. Der heikle Punkt liegt in der fehlenden Kompetenz,

welche die Projektverantwortlichen ermächtigt, Entscheide selber zu fällen und anderen

Personen Weisungen zu erteilen (Abb. 4.2).

Kompetenz

Aufgaben

Verantwortung

Verantwortung und Kompetenz

sind immer aufgabenbezogen

Aufgabe formulieren

Verantwortung übertragen

Durch Übernahme einer

Aufgabe übernehme

ich die Verpﬂichtung, ein

Resultat zu liefern

Kompetenz erteilen

Ermächtigung

und Handlungsfreiheit

ermöglichen, dass die Aufgabe

erfüllt werden kann

Besteht keine Kongruenz

zwischen den 3 Dimensionen,

sind Konﬂikte wahrscheinlich

Abb. 4.2 Das Kongruenzprinzip A-K-V

358

Team

Die Ausgestaltung des Kompetenzbereiches der jeweiligen Projektrollen bildet einen

wesentlichen Erfolgsfaktor in der Abwicklung der Projekte. Projekte können operativ

noch so gut geführt werden. Wenn die Projektorganisation die Kompetenz für ihre Aufga-

ben und Ziele nicht hat, wird sie nicht erfolgreich arbeiten können.

Im klassischen Projektmanagement muss das Machtsystem zwischen Auftraggeber und

Projektleitung und den Linienvorgesetzten austariert werden: Der Auftraggeber muss

in der Stammorganisation genug „mächtig“ sein, um dem Projektleiter das Budget und

die effektiv benötigten Ressourcen zur Verfügung stellen zu können. Der Projektleiter

braucht vom Auftraggeber einen klaren Projektauftrag, in welchem er auch seine Ziele,

Verantwortung und Kompetenzen – und damit seine Weisungsbefugnis gegenüber dem

Projektteam – klärt. In der Projektkoordination und in der Matrix ist die Abstimmung mit

den Linienvorgesetzten ebenfalls wesentlich.

Im agilen Ansatz wird die Macht zwischen dem Product Owner sowie dem Team

aufgeteilt: Der Product Owner führt das Projekt inhaltlich. Dafür benötigt er die Ent-

scheidungskompetenz, die Sprint-Resultate des Teams abzunehmen. Wenn dies nicht der

Fall ist – das ist in der Praxis immer wieder der Fall –, weil er Rücksprache halten muss

mit anderen Entscheidungsträgern und Organen, wird der Prozess ineffektiv. Der Product

Owner ist gefangen in einer Aufgabe mit Verantwortungen, für welche er keine Kompe-

tenzen hat. Das Team selber ist in dem Sinne ermächtigt, dass es während eines Sprints

eigenständig entscheiden kann, wie viele Anforderungen während eines Sprints umgesetzt

werden und dass es sich selber organisieren kann und muss.

Provokativ formuliert, handelt es sich bei Product Ownern und Projektleitern ohne

Weisungsbefugnisse und Entscheidungskompetenzen um „lahme Enten“: Sie haben viele

Aufgaben und Verantwortung, aber keine Kompetenzen. Zu einem Teil kann dies durch

persönliche Macht kompensiert werden.

4.1.6

Vom vorauseilenden Gehorsam in den konstruktiven Ungehorsam

Die Überlegungen zum Thema Macht und A-K-V zeigen einen heiklen Punkt in der Pro-

jektarbeit: Projektverantwortliche müssen sich emanzipieren, um von den Inhabern der

institutionellen Macht der Stammorganisation Rahmenbedingungen und damit eine Er-

mächtigung zu erhalten, die ihrem Auftrag, dem methodischen Ansatz und ihrer Rolle

entsprechen.

Nur sehr reﬂektierte Entscheidungsträger in Projektorganisationen sind für dieses The-

ma genügend sensibilisiert und statten die Projektverantwortlichen von Grund auf mit

allen Kompetenzen aus, welche sie für ihren Auftrag brauchen. In allen anderen Fällen

müssen v. a. Projektleiter und Product Owner sicherstellen, dass sie mit allen Kompe-

tenzen ausgestattet sind, welche sie zur Erfüllung der Aufgaben und zum Tragen ihrer

Verantwortung benötigen. Dies muss während der Projektbeauftragung und Initialisierung

geschehen.

4.1

Zusammenarbeit und Führung

359

Den vorauseilenden Gehorsam haben wir alle in der Familie, der Schule oder auch in

den ersten Berufsjahren gelernt. Wir haben da gelernt, dass es gut ist, die Erwartungen der

Bezugspersonen zu erfüllen. Irgendwann im Erwachsenenleben, und sicher früher oder

später in einer Projektverantwortung, werden wir erfahren, dass wir schlichtweg nicht

mehr alle Erwartungen erfüllen können, die an uns gestellt werden. Dann geht es darum,

den anspruchsvollen Weg in den konstruktiven Ungehorsam zu erlernen: realistische Pro-

jektaufträge auszuhandeln, Grenzen für sich und sein Team zu setzen und manchmal auch

die Entscheidungsträger unter Druck zu setzen.

Beispiel

Wenn ein Projektauftrag zu wenig sorgsam oder auch kritisch geprüft wird und sich

der Projektleiter nicht getraut, unrealistische Vorgaben zu thematisieren oder zu ver-

handeln, überfordert er damit nicht nur sich selbst, sondern auch sein ganzes Team.

Diese Aufgabe ist schwierig, weil mit unterschiedlichen Hierarchieebenen verhandelt

werden muss. Meistens ist der Auftraggeber gegenüber seinem Verhandlungspartner um

eine oder mehrere Hierarchieebenen höher angesiedelt.

Für Product Owner und Projektleiter ist es deshalb wesentlich, sich nicht vor lauter

Loyalität zum Hierarchen in einem vorauseilenden Gehorsam für alle Projektaufgaben

vorbehaltlos einspannen zu lassen. Vielmehr liegt ein kritischer Erfolgsfaktor in ihrer Ar-

beit darin, dass sie es schaffen, mit dem Auftraggeber so lange zu verhandeln, bis ihr

Projekt die Rahmenbedingungen hat, welche es zur erfolgreichen Bearbeitung braucht. Es

geht in der frühen Phase des Projektes also darum, über einen äußerst anspruchsvollen

konstruktiven Ungehorsam den Verantwortlichen der Linienorganisation die entspre-

chenden Kompetenzen „abzutrotzen“. Das widerstrebt natürlich unserer intuitiven Hal-

tung, unseren Vorgesetzten gefallen zu wollen. Doch kommt gerade in der standhaften und

ausdauernden Verhandlung um optimale Rahmenbedingungen für das Projekt die Projekt-

kompetenz der Projektverantwortlichen zum Ausdruck.

Im klassischen Projektmanagement dreht sich dabei alles um den Projektauftrag, das

Dokument, in welchem das Mandat des Projektleiters abschließend vereinbart und festge-

halten wird. Dieser Projektauftrag muss so lange zwischen Auftraggeber und Projektleiter

verhandelt und weiterentwickelt werden, bis das oben dargestellte Kongruenzprinzip so

gut wie möglich erreicht worden ist. Das sinngemäße Dokument ist im agilen Projekt-

management die Produktvision.

4.1.7

Unterschiedliche Ausprägungen von Führung

Ein Projekt wird vordergründig immer an der Zielerreichung und damit an der Arbeit

im System (Abschn. 1.5.1 und 4.2.4) gemessen. Damit dies geschehen kann, müssen

jedoch wesentliche Rahmenbedingungen auf der Beziehungs- und Organisationsebene

360

Team

geschaffen, es muss am System gearbeitet werden. Für die Arbeit am System gibt es un-

terschiedliche Ausprägungen von Führung:

Führung = Management

Im umfassenden betriebswirtschaftlichen Sinn versteht man darunter das Führen und

Leiten eines Unternehmens, einer Organisation oder eines Projektes usw. Die Unterneh-

mensführung beschäftigt sich mit der Existenzsicherung des Unternehmens unter den

wechselnden Rahmenbedingungen. Sie beurteilt Einﬂüsse des Umfeldes und nutzt die

gewonnenen Erkenntnisse für die Anpassung des Unternehmens an die Begebenheiten.

Im Innern berücksichtigt sie die vorhandenen Stärken, Fähigkeiten und Ressourcen. Aus

der Kombination der äußeren und der inneren Einﬂussfaktoren werden die Strategien, die

Unternehmensziele und die Unternehmenspolitik abgeleitet. Analog dazu kann das Ma-

nagen eines Projektes verstanden werden als die Existenzsicherung des Projektes in der

Organisation und die permanente Anpassung an die wechselnden Rahmenbedingungen

und Einﬂussfaktoren.

Führung = Mitarbeiterführung

Im engeren Sinn spricht man von Führung, wenn eine bewusste und zielorientierte Ein-

ﬂussnahme auf Mitarbeiter ausgeübt wird. Die Mitarbeiterführung wird durch die Verän-

derungen im Umfeld geprägt. Eine intelligente Unternehmensführung kann sich rasch auf

neue Situationen einstellen. Sie braucht viele kompetente Menschen, die Bescheid wissen

und die bereit sind, mitzudenken, zu handeln und Verantwortung zu übernehmen. Dazu

braucht es eine hohe Transparenz im Bereich von Information und Kommunikation, ein

koordiniertes Zusammenspiel aller Beteiligten und großes Vertrauen zwischen Mitarbei-

tern und Führungskräften. Führen heißt hier, Einﬂuss zu nehmen auf das Verhalten der

Mitarbeiter, so dass mit ihnen zusammen die Ziele erreicht werden können. Wenn es al-

so darum geht, zielorientierte Anordnungen zu erteilen, einzufordern und zu korrigieren,

dann nimmt der Projektverantwortliche wie eine Führungskraft die Rolle der Mitarbeiter-

führung wahr.

Führung = Coaching

Der Projektverantwortliche hat auch die Aufgabe, seine Mitarbeiter ressourcenorientiert

zu unterstützen, zu fördern und ihre Persönlichkeit zu entwickeln. Dafür steht der Begriff

Coaching. Es ist ein Element der partnerschaftlichen Führung und eine sinnvolle Ergän-

zung zu den anderen Instrumenten der Personalentwicklung. In der Rolle des Coachs ist

er Begleiter und Trainer. Er verfolgt das Ziel, seine Projektmitarbeiter so zu unterstüt-

zen, dass sie selbständig und eigenverantwortlich handeln können. Die Coaching-Qualität

zeichnet sich durch realistische Umsetzung, konkrete Resultate und Nachhaltigkeit aus.

Führung = Dynamische und dezentral verteilte Führungsarbeit

In der kollegialen Führung fällt die eigentliche Führungskraft weg. Die Führungsarbeit –

und damit die gesamte Arbeit am System – wird unter den Teammitgliedern verteilt. Das

4.1

Zusammenarbeit und Führung

361

bedeutet nicht, dass jeder die Führungsarbeit antizipieren muss, sondern dass verschiedene

Rollen situativ durch unterschiedliche Teammitglieder wahrgenommen werden.

Führungsausprägungen im Projektmanagement

Abschließend setzen wir die oben dargestellten Ausprägungen von Führung in Bezug zu

den in Abschn. 2.3.9 dargestellten Aufgaben der Projektgremien.

Mit der Unterzeichnung des Projektauftrages übernimmt der Projektleiter die tempo-

räre Mitarbeiterführung, das Coaching sowie die Management-Aufgabe für sein Projekt

und das Team. Die Management-Aufgabe nimmt er durch das Controlling wahr. Es ist die

Verantwortung des Projektleiters, während der Projektabwicklung sämtliche Abweichun-

gen zum initialen Plan zu erkennen und zu bearbeiten. Aus jeder erkannten Abweichung

muss eine Maßnahme resultieren. Für das Entwickeln und Bewerten der Maßnahmen eig-

net sich der Problemlösungsprozess.

Alle nach den umgesetzten Maßnahmen verbleibenden Abweichungen, die einen Ein-

ﬂuss auf das magische Dreieck haben, muss der Projektleiter seinem Auftraggeber mel-

den. Durch das Reporting kommt der Auftraggeber seinerseits in die Management-Funk-

tion. Auch dazu dienen die über den Problemlösungsprozess bewerteten Lösungsalter-

nativen als Entscheidungsgrundlage. Der Auftraggeber fokussiert sich in Bezug auf das

Coaching und die Mitarbeiterführung auf den Projektleiter. Dieser übt seine Führungs-

aufgabe gegenüber seinen Teilprojektleitern und – in einem geringeren Maße – auch

gegenüber einzelnen Experten aus.

Im agilen Projektmanagement sind diese Ausprägungen klarer den jeweiligen Rollen

zugeordnet: Der Product Owner – verantwortlich für die inhaltliche Führung des Projektes

– fokussiert sich auf die Management-Aufgabe. Der Scrum Master übernimmt das Coa-

ching. Eine eigentliche Mitarbeiterführung gibt es im agilen Ansatz nicht. Diese erfolgt

durch die in Abschn. 4.1.12.3 erläuterte Selbststeuerung.

4.1.8

Delegation

Zu delegieren ist für viele Projektverantwortliche eine große Herausforderung. Meistens

qualiﬁzieren sich diese durch gute Arbeit als Fachexperten in der Stammorganisation für

eine Projektrolle. Mit der Projektleitung, der Teilprojektleitung, als Scrum Master, Pro-

duct Owner oder im Projektteam übernehmen sie neue Rollen. Diese bringen viele neue

Aufgaben und Verantwortlichkeiten mit sich. Damit diese Projektrollen überhaupt wahr-

genommen werden können, müssen alle Betroffenen Kapazitäten freilegen. Hierfür ist

das Prinzip der Delegation hilfreich, sei es in Bezug auf Linien- oder Projektaufgaben.

Im operativen agilen Projektmanagement spielt die Delegation keine Rolle, da das

Team in Selbststeuerung unterwegs ist und sehr dynamisch entscheidet, wer wann was

tut.

362

Team

Ich wähle

eine Aufgabe

und frage

mich…

… ist sie notwendig?

… kann nur ich

sie erfüllen?

… warum?

zu wenig verfügbar

ist Führungsaufgabe

• Auslastung über-

prüfen

• Einsatzplanung prüfen

• Person für temporären

Einsatz suchen

• Person ausleihen

• Neue Person

einstellen

• Kann die Arbeit

vereinfacht werden?

• Kann sie auch später

erledigt werden?

• ausbilden

• begleiten

• instruieren

• beraten

• erläutern

• über Hierar-

chie klären

nicht übertragbar

nein

Er weiss oder

kann es nicht

Er will oder

darf es nicht

eliminieren

delegieren

nach Checkliste

warum?

Abb. 4.3 Entscheidungsprozess in der Delegation

Entscheidungsprozess in der Delegation

Wie kann konkret delegiert werden? Abb. 4.3 zeigt den Entscheidungsprozess auf, ob und

wie sich eine Aufgabe zur Delegation eignet: Zuerst ist zu prüfen, ob die Aufgabe für die

Organisation oder das Projekt wirklich notwendig ist. Für diese Klärung ist auch die Zeit-

management Matrix in Abschn. 3.8.3 hilfreich. Unnötige Aufgaben sind zu eliminieren.

Für verbleibende Aufgaben ist eine Person mit den erforderlichen Kompetenzen zu ﬁnden.

Gibt es eine Person, die bereit, willens und in der Lage ist, diese Arbeit zu erledigen, kann

die Aufgabe nach der Checkliste in Tab. 4.4 delegiert werden. Wenn im Moment nur ich

selber die Aufgabe erfüllen kann, muss ich fragen:

Ist die Aufgabe nicht übertragbar, weil . . .

niemand vorhanden ist, der das entsprechende Wissen oder die Kompetenzen hat?

Dann ist eine solche Person aufzubauen.

die Kompetenzen zwar vorhanden sind, aber die entsprechende Person den Auftrag

nicht übernehmen kann? Dann sind die Gründe zu eruieren. Die passende Ressource

ist über die Hierarchie freizusetzen.

4.1

Zusammenarbeit und Führung

363

Tab. 4.4 Checkliste in der Delegation

Fokus

Beschreibung

WAS

Systemziele

– Welches Ergebnis wird angestrebt?

– Welche Teilaufgaben sind im Einzelnen zu erledigen?

– Welche Schwierigkeiten sind zu erwarten?

WER

Personen und

Hierarchiestufen

– Wer ist geeignet, diese Aufgabe oder Tätigkeit auszuüben?

– Ist der Betreffende verfügbar?

– Wer soll bei der Ausführung mitwirken?

WOZU

Sinn und Motivation

– Welchem Zweck dient die Aufgabe oder Tätigkeit?

– Was passiert, wenn die Aufgabe nicht ausgeführt wird?

WOMIT

Mittel, Ressourcen

– Womit muss der Mitarbeiter ausgerüstet oder ermächtigt sein?

– Welche Unterlagen werden benötigt?

WANN

Termine

– Wann muss die Arbeit abgeschlossen sein?

– Welche Zwischentermine sind einzuhalten?

VERANTWORTUNG

des Delegierenden

– Inwiefern bleibe ich Teil der Lösung?

– Welche Verantwortung bleibt bei mir gegenüber wem?

– Wann muss ich was kontrollieren, um ggf. einzugreifen?

Eventuell: WIE

Vorgehensziele

– Wie soll bei der Ausführung vorgegangen werden?

– Welche Vorschriften und Richtlinien sind zu beachten?

– Welche Stellen/Abteilungen sind zu informieren?

Sind zu wenige Ressourcen verfügbar, prüfe man die Auslastung und die Einsatzpla-

nung. Die delegierende Person muss sich um zusätzliche Ressourcen bemühen. In solchen

Situationen sind die Aufgaben zu vereinfachen oder auf einen späteren Zeitpunkt zu ﬁxie-

ren.

Speziﬁsche Führungsaufgaben können nicht delegiert werden.

Delegation als wiederkehrender Prozess in der Projektleitung

Im klassischen Ansatz muss sich der Projektleiter immer wieder neu fragen, welche Auf-

gaben er selber ausführt und welche er an andere Personen delegiert. Per Deﬁnition sollte

er v. a. am System arbeiten und nicht im System.

Erfolgreiches Delegieren erfordert zunächst die Fähigkeit, Aufgaben sinnvoll vonein-

ander abzugrenzen. Dann müssen diese verständlich kommuniziert und die unterschiedli-

chen Aufgabenfelder koordiniert werden. Schließlich müssen die erzielten Ergebnisse in

das große Ganze integriert werden.

Dass der Delegationsempfänger seine eigenen Wege zur Aufgabenerfüllung wählt, ist

ein Risiko der Delegation. Der Mitarbeiter muss die ursprünglichen Strategien kennen,

damit er das liefern kann, was im Gesamtkontext erwartet wird. Delegation ist ohne Ver-

trauen unmöglich. Wer kein Vertrauen zu seinen Mitarbeitern hat, kontrolliert und wird

zum Micro-Manager (Abschn. 3.3.7). Gerade der Beginn eines Delegationsprozesses ist

zeitaufwändiger und risikoreicher, als wenn man die Aufgabe selber erledigen würde.

Mittel- und langfristig ist es jedoch der einzige Weg, das Team als Ganzes weiterzuentwi-

ckeln und seine eigenen Ressourcen für die wichtigen Aufgaben bereitzuhalten. Nützliche

364

Team

Tugenden in diesem Prozess sind Offenheit, Toleranz und die Gelassenheit, dass Aufgaben

auch auf andere als die erwartete Art erledigt werden können.

Beispiel

Es gibt eine Vielzahl von Argumenten, die speziell im Projektmanagement für Delega-

tion sprechen:

Entlastung der Projektverantwortlichen, d. h. mehr Zeit für die wesentlichen Aufga-

ben und Verantwortlichkeiten der jeweiligen Rollen.

Aus dem Rollenverständnis heraus müssen die Teammitglieder in ihrem Sachgebiet

kompetenter sein als ein Projektleiter.

Entscheidungen können von denjenigen Fachleuten vorbereitet und getroffen wer-

den, bei denen die Folgen unmittelbar wirksam werden.

Durch die Delegation eröffnen sich in der Projektarbeit oft die für Kreativität in der

Lösungssuche notwendigen Freiräume.

Delegation heißt auch Einbezug der Mitarbeiter. Sie werden gefordert und dadurch

gefördert. Durch die Übernahme von Verantwortung erhöht sich die Qualiﬁkation

der Auftragnehmer.

Qualiﬁzierte Mitarbeiter wollen in der Regel ihr Potenzial einsetzen und zeigen kön-

nen. Mit dem Delegationsprinzip betont die delegierende Person ihr Vertrauen in ihre

Mitarbeiter und verstärkt gleichzeitig deren Selbständigkeit und Handlungsfähigkeit.

Neben diesen Argumenten, die für das Delegationsprinzip sprechen, sind die Gefahren

zu erwähnen. Wichtig erscheint in diesem Zusammenhang, dass die delegierende Person

dafür besorgt ist, dass:

die „richtigen“ Mitarbeiter eingesetzt werden, d. h. die Gefahr der Über- und Unterfor-

derung geklärt wird, bevor die Mitarbeiter ins Projekt eingeplant werden;

die Mitarbeiter umfassend informiert sind, d. h., dass sie nebst Ziel und Zweck auch

die Zusammenhänge verstanden haben;

Ausführungs- und Ergebniskontrolle planmäßig und systematisch erfolgen (Statusbe-

richte, Meilensteine);

mit der Delegation von Arbeitsaufgaben die entsprechenden Kompetenzen erteilt und

die Verantwortung übertragen wird (Abschn. 4.1.5).

4.1.9

„Aufstellung“ in Teams: Position und Rolle

Wer einen Spielﬁlm produzieren will, muss ganz unterschiedliche Positionen besetzen: Es

braucht einen Autor für das Drehbuch, einen Regisseur, Schauspieler, Statisten, Kamera-

männer, Studiomitarbeiter, jemanden, der die Finanzierung regelt und noch viele andere

mehr. Eine der Grundvoraussetzungen, dass die Arbeit erfolgreich sein wird, ist es, dass

4.1

Zusammenarbeit und Führung

365

die notwendigen Positionen deﬁniert werden. Dementsprechend werden diese Positionen

mit geeigneten Personen besetzt.

Eine Organisation ermächtigt Positionen

Positionen beschreiben den formalen oder informellen Platz in einer Organisation (Ruth Se-

liger).

Bei genauer Betrachtung ermächtigen Organisationen nicht einzelne Personen (Linien-

vorgesetzte). Sehr viel mehr wird die Macht auf Positionen der Stammorganisation zu-

geordnet: Stammorganisationen werden hierarchisch aufgeteilt nach Zuständigkeitsberei-

chen. CEO, CFO, Leiter Projektmanagement, Teamleiter Logistik oder Kunden-Projekt-

leiter können Positionsbeschreibungen sein. Über diese Positionen klärt eine Organisa-

tion ihre Zuständigkeitsbereiche, legt gewissermaßen ihre „Aufstellung“ fest. An diese

Positionen delegiert eine Organisation Status- und Entscheidungsmacht. Diese Kompe-

tenzen sind nicht an einzelne Personen gebunden und bleiben auch bestehen, wenn es

zu einem Stellenwechsel kommt. Sie können auch an andere Personen delegiert werden

(Abschn. 4.1.3).

Eine Position beinhaltet mehrere Rollen

Wer im Umfeld vom Projektmanagement arbeitet, hat – außer in der reinen Projektorga-

nisation – innerhalb seiner Position immer mehrere Rollen abzudecken. Die Position des

Leiters Projektmanagement beinhaltet ganz unterschiedliche, in Bezug auf das Projekt-

management auch nur temporäre Aufgaben. Diese bezeichnen wir als Rollen.

Beispiel

So kann der Leiter Projektmanagement verantwortlich sein für die Bewirtschaftung des

Projektportfolios der gesamten Organisation und für die Entwicklung und Durchset-

zung der Projektmanagement Guidelines und Standards. Er nominiert die Projektleiter

und führt diese disziplinarisch und fachlich. Es obliegt ihm auch die Budgetverant-

wortung für sein Team. Zusätzlich nimmt er unterschiedliche temporäre Rollen in

speziﬁschen Projekten ein.

Die Position des Kunden-Projektleiters beinhaltet ganz andere Rollen: Nebst Pro-

jektleiter ist er z. B. Kundenbetreuer oder stellt – im Bereich seiner technischen Kom-

petenzen – den 3rd Level Support sicher.

Dies gilt natürlich auch für die Rollen im agilen Projektmanagement. Die speziﬁschen

Kompetenzen und Führungsaufgaben in den jeweiligen Rollen sind unter Abschn. 2.3.9.3

detailliert beschrieben.

In Abb. 4.4 ist eine Organisation mit den Positionen und Rollen dargestellt.

366

Team

CEO

R + D

Produkt

Finanzen

Verkauf

Exp 2

Exp 1

TPL 1

TPL 2

Projekt

Product Owner

Scrum Master

Team

Projekt

Positionen

Rollen

Soz

iale

s S

yste

m O

rga

nis

atio

Abb. 4.4 Position und Rollen in Organisationen

Rollen reduzieren Komplexität und schaffen Vertrauen

Durch Rollen können wir in einem sozialen System die Komplexität verringern: Je besser

wir den „Verhaltenserwartungen“ (Ruth Seliger) unserer Mitmenschen gerecht werden,

desto einfacher ist es für diese, uns einzuordnen. Damit entsteht für alle Beteiligten au-

tomatisch mehr Sicherheit. Das Gefühl der Sicherheit ist wiederum Grundvoraussetzung

dafür, dass zwischen einzelnen Menschen und – als Konsequenz davon – in einem Team

oder in einer Organisation Vertrauen entstehen kann (Abschn. 3.3.7).

Die eigenen Rollen zu klären, gehört zur Selbstverantwortung jedes Mitarbeiters. Viel-

fach müssen diese Rollen richtiggehend verhandelt werden, weil die Erwartung und der

Anspruch der Organisation die Möglichkeiten der einzelnen Personen immer wieder über-

steigen. Je klarer diese Rollen deﬁniert sind und je besser sie nach dem Kongruenzprinzip

A-K-V (Abschn. 4.1.5) abgestimmt sind, desto effektiver ist die Arbeit der einzelnen Per-

sonen und der Organisation insgesamt.

4.1

Zusammenarbeit und Führung

367

4.1.10

Rollenträger und Rollensender

Die Rollensender bestimmen das Verhalten des Rollenträgers

Unser Spielﬁlm wird allein mit einem spannenden Drehbuch und mit klar deﬁnierten Po-

sitionen und Rollen noch kein Kassenschlager. Der Erfolg hängt u. a. davon ab, ob der

Regisseur Schauspieler ﬁndet, welche es schaffen, die Rollen so authentisch spielen zu

können, dass sie die Zuschauer in ihren Bann ziehen können.

Die verbale Kommunikation, den Text auswendig zu können, reicht dafür bei Wei-

tem nicht. Der Star unterscheidet sich vom normalen Schauspieler durch die Fähigkeit,

wie glaubwürdig und wirkungsvoll er die Rolle verkörpern kann, v. a. durch non-verbale

Kommunikation. Und dies hängt wiederum davon ab, wie gut der Schauspieler den Er-

wartungen des Publikums gerecht werden kann. Sei es der Held, der Bösewicht oder der

Clown: Die Zuschauer haben Erwartungen, wie sich z. B. ein Clown in speziﬁschen Situa-

tionen verhalten soll. Sie senden diese Erwartungen (Rollensender) an den Rollenträger.

Das Verhalten eines Rollenträgers in einer speziﬁschen Situation bezeichnen wir als

gelebte Rolle. Die Zuschauer sind in diesem Beispiel mit ihren Erwartungen an die Rolle

Clown also die Rollensender. Der Clown ist der Rollenträger.

Das Phänomen der gelebten Rolle ist, dass der Rollenträger sich den Erwartungen der

Rollensender anpassen muss, um wirkungsvoll und glaubwürdig zu sein.

Während also Position und Rolle beschreiben, WAS ein Stelleninhaber zu leisten hat,

beschreibt die gelebte Rolle des Rollenträgers das WIE.

Der Authentizitäts-Hype

Oft wird geschrieben, (Führungs-)Erfolg hänge davon ab, authentisch zu sein. Wir wären

damit legitimiert oder sogar dazu aufgerufen, uns in jeder Situation einfach so zu ver-

halten, wie es uns gerade persönlich entsprechen würde. Dies widerspricht ganz klar den

obigen Ausführungen, die darauf zielen, dass über vorhersagbares Verhalten von Rollen-

trägern Sicherheit entsteht. Auch Rolf Dobelli rät, im Beruf den Authentizitäts-Hype nicht

mitzumachen: „Authentizität hat ihren berechtigten Platz innerhalb einer Lebenspartner-

schaft oder einer sehr engen Freundschaft, aber nicht gegenüber ﬂüchtig Bekannten und

schon gar nicht gegenüber der Öffentlichkeit“ (Dobelli 2017, S. 65). In der Arbeit geht

es um Respekt und nicht um Liebe. Wir respektieren die Menschen, die halten, was sie

versprechen, deren Verhalten uns gegenüber wir vorhersagen können.

4.1.11

Rolle als Bindeglied zwischen Organisation und Person

Die gelebte Rolle ist abhängig vom Kontext

Der Clown verhält sich an einem Kindergeburtstag anders als in einem Kinoﬁlm. In der

Rolle des Freundes verhalten wir uns im intimen Rahmen zu zweit anders, als wenn noch

weitere Personen dabei sind.

368

Team

Die vom Rollenträger gelebte Rolle ist stark vom Kontext abhängig. Rollenträger pas-

sen sich dem Kontext meistens unbewusst an. Ohne es effektiv zu merken, verhalten wir

uns je nach Situation anders und versuchen damit, den Erwartungen der beteiligten Perso-

nen – der Rollensender – gerecht zu werden.

Beispiel

In der einen Organisation muss ein Projektleiter seinem Auftraggeber gegenüber be-

stimmt auftreten können, unternehmerisch denken und bei Verzögerungen auch in

der Lage sein, die Linienvorgesetzten, welche die Ressourcen freistellen sollen, unter

Druck zu setzen.

In einer anderen Organisation wäre genau dieses Verhalten ein Affront: Hier wird

vom „Projektleiter“ erwartet, dass er als „Mädchen für alles“ fungiert, für alle und

alles als Ansprechpartner gilt, aber keinesfalls auf die Entscheidungskompetenzen der

Vorgesetzten Einﬂuss nimmt.

Der Scrum Master, der eine Sprint Retrospektive mit einem Team moderiert, wel-

ches noch nie agil gearbeitet hat, muss stärker intervenieren und auch geduldiger sein,

als wenn er mit einem Team zusammenarbeitet, welches schon mehrere Projekte in

derselben Konstellation abgewickelt hat.

Natürlich sind wir in der Art und Weise, wie wir eine Rolle leben, beschränkt. Wir

können nicht jede Rolle übernehmen, weil wir unser Denken, Fühlen und Handeln nicht

einfach entkoppeln können von unserer Person mit unseren Werten, Fähigkeiten, Prägun-

gen oder Charakterzügen.

Die gelebte Rolle ist sichtbar im Kontakt zwischen Rollenträger und Rollensender

Erfolgreiche Projektarbeit basiert auf klar deﬁnierten und vereinbarten Rollen. Die Rol-

lenträger müssen dabei den Erwartungen der anderen Rollensender entsprechen. Diese

Rollensender sind Teil einer sie umgebenden Organisationsstruktur und -kultur, die ih-

rerseits wiederum Einﬂuss hat auf deren Erwartungen. Dies alles schafft den Kontext, in

welchem sich der Kontakt zwischen Rollenträger und Rollensender ereignet, wie dies im

oberen Teil der Abb. 4.5 dargestellt ist. In dieser Schnittstelle ergibt sich die gelebte Rol-

le des Rollenträgers. Diese Schnittstelle hat ein hohes Konﬂiktpotenzial: Je größer die

Diskrepanzen, desto wahrscheinlicher die Rollenkonﬂikte (Abschn. 4.4.7.4).

Rollenübernahme

Je besser die Rollen deﬁniert sind, desto besser ist das Zusammenspiel im Team und desto

geringer ist die Wahrscheinlichkeit, dass Rollenkonﬂikte auftreten werden. Diesen Pro-

zess der bewussten Ausgestaltung einer gelebten Rolle wird Rollenübernahme genannt

(Steiger und Lippmann 2008, S. 49 ff.).

In jeder Organisation haben die Rollensender und auch die Rollenträger speziﬁsche Er-

wartungen, WIE sich ein Projektleiter oder ein Scrum Master in speziﬁschen Situationen

zu verhalten hat. Im Gegensatz zu den Positionen und Rollen ist diese Rollenübernahme

4.1

Zusammenarbeit und Führung

369

gelebte

Rolle

Person

Rollenträger

Organisation

andere Rollensender

Rollenübernahme

Rollen-

verständnis

Prägung

Charakter

Werte

Fähigkeiten

Autorität

Rollen-

erwartung

Auftrag

Kultur

Ressourcen

A-K-V

ﬁ

Abb. 4.5 Gelebte Rolle als Schnittstelle zwischen Person und Organisation

aber oft nicht explizit festgelegt, sondern ist geprägt durch das in der Organisationskultur

bewusst oder unbewusst verankerte Rollenverständnis oder durch Rollenerwartungen.

Eine erfolgreiche – und damit bewusst gestaltete – Rollenübernahme basiert auf den

folgenden drei Maßnahmen:

Rolle deﬁnieren: Basierend auf Position und Rolle muss in einem ersten Schritt deﬁ-

niert werden, wie eine Rolle ausgeführt werden soll und damit auch, welche Erwartungen

die Rollensender und der Rollenträger haben.

Beispiel

Der Scrum Master mit einem Projektteam von agilen Novizen muss für sich selber, aber

auch für seine Anspruchsgruppen wie den direkten Vorgesetzten oder den Project Ow-

ner klären können, in welcher Bandbreite er das Team in seinem Prozess unterstützen

kann und soll.

Rolle gestalten: Nun wird die Rolle ausgefüllt. Der Kontakt zwischen dem Scrum

Master als Rollenträger sowie dem Team als Rollensender ist davon geprägt, wie stark

die Rahmenbedingungen durch die Organisation resp. die Führungsverantwortlichen der

Stammorganisation beeinﬂusst werden. Die Organisation wirkt unterstützend, kann aber

370

Team

auch Hindernisse schaffen, wie suboptimale Werkzeuge oder ungenügend freigestellte

Teammitglieder für das Projekt.

Beispiel

Der Scrum Master identiﬁziert sich mehr oder weniger mit dem Projekt und dessen

Zielen – was auch abhängig davon ist, wie viele andere Projekte er gleichzeitig betreut

und wie optimal er die Rahmenbedingungen einschätzt. Er bringt sich ein mit seinen

Erfahrungen und Fähigkeiten, aber auch mit seinen Hemmnissen und Beschränkungen.

Rolle durchsetzen: Früher oder später fallen wir alle aus einer noch so gut deﬁ-

nierten und gestalteten Rolle. Sei das begründet aus dem Teamentwicklungsprozess

(Abschn. 4.2), wegen eines Rollenkonﬂikts oder weil sich Stress breitmacht, die betrof-

fenen Personen wie auch die involvierten Organisationsvertreter sind in dieser Situation

herausgefordert, die jeweiligen Rollen immer wieder neu durchzusetzen.

Beispiel

Der Scrum Master darf nicht beginnen, Einﬂuss zu nehmen auf die Selbstorganisation

seines Teams. Der Product Owner muss mit den Entscheiden leben können, welche ein

Team während eines Sprints fällt. Das Team wiederum muss damit leben können, dass

der Product Owner die Resultate eines Sprints nicht abnimmt, sofern die Ziele nicht zu

100 % erreicht sind.

Rollen zu deﬁnieren, zu gestalten und durchzusetzen ist ein fortlaufender Prozess,

der entsprechend der Teamdynamik immer wieder Aufmerksamkeit braucht. Nach dem

Grundsatz von „Störungen haben Vorrang“ (Abschn. 4.4.12.2) gilt es, Grenzverletzun-

gen zwischen den Rollen und damit mögliche Friktionspunkte frühzeitig zu erkennen und

auf der Basis von gut entwickelten Kompetenzen in der persönlichen Kommunikation zu

bearbeiten. Wenn z. B. der Scrum Master auf die Selbstorganisation des Teams Einﬂuss

nimmt, muss ihm das mitgeteilt werden können in einer konstruktiven Art und Weise. Al-

le Involvierten müssen also Feedback geben und empfangen können (Abschn. 3.9.7), um

danach die Rollenübernahme gemäß den oben ausgeführten drei Schritten weiterzuentwi-

ckeln. Der Ansatz der Belbin Teamrollen (Abschn. 4.1.14.1) oder auch die RACI-Matrix

(Abschn. 2.3.9.9) sind für diesen Prozess ebenfalls sehr hilfreich.

4.1.12

Spezifische Eigenschaften im agilen Projekt

Welche speziﬁschen Eigenheiten oder Methoden sollen oder können berücksichtigt wer-

den in der Übernahme der Rollen Product Owner, Scrum Master und Team?

4.1.12.1

Grundsätze

Agiles Projektmanagement wurde für Projekte entwickelt, die komplex, voller Überra-

schungen und Unsicherheiten sind. Entsprechend ﬂexibel, beweglich und innovativ muss

4.1

Zusammenarbeit und Führung

371

nicht nur das Vorgehen, sondern auch die Projektorganisation sein. Deshalb ist in agi-

len Organisationen die Führung nicht mehr nur an eine Person gebunden. Sie wird als

Führungsarbeit verteilt wahrgenommen. Für den Product Owner bedeutet Führung vor al-

lem, den inhaltlichen Rahmen zu setzen und Kontexte zu gestalten, damit Teams optimal

arbeiten können. Der Scrum Master fokussiert sich darauf, den Teams bei Bedarf Unter-

stützung zu bieten, um sich selber optimal managen zu können. Man spricht deshalb auch

von servant leading.

Das Team selber „führt“ sich durch Selbstorganisation, oder Selbststeuerung: Dies

geschieht entweder situativ verteilt oder aus den verschiedenen Rollen. Bis anhin wurden

damit gute Erfahrungen in Scrum-Projekten gemacht. Mehr und mehr werden auch andere

als nur Software-Projekte mit Selbststeuerung geführt.

4.1.12.2

Gewichtete Kompetenzprofile Product Owner und Scrum Master

Die in Abb. 4.6 dargestellten Kompetenz-Anforderungsproﬁle an einen Product Owner

sowie an einen Scrum Master basieren auf dem Kompetenzmodell in Abschn. 3.1.

Methoden-

kompetenz

Selbst-

kompetenz

Sozial-

kompetenz

Verhandlungs-

kompetenz

Fach-

kompetenz

Team- und

Führungs-

kompetenz

Methoden-

kompetenz

Selbst-

kompetenz

Sozial-

kompetenz

Verhandlungs-

kompetenz

Fach-

kompetenz

Team- und

Führungs-

kompetenz

Product Owner

Scrum Master

Legende:

0 nicht relevant

1 nicht nötig

2 hilfreich

3 wichtig

4 Voraussetzung

Abb. 4.6 Gewichtete Kompetenzproﬁle im Agilen Projektmanagement

372

Team

4.1.12.3

Wie funktioniert Selbststeuerung?

In selbstgesteuerten Teams wird kollegial geführt. Die kollegiale Führung wird verteilt, si-

tuativ und temporär wahrgenommen. Je nach Fähigkeiten und Temperament sind die einen

Teammitglieder führend in der Ideenﬁndung, andere im „Machen“, dritte habe ein Senso-

rium für die sozialen Prozesse usw. Mit diesen unterschiedlichen Präferenzen muss sich

das Team auseinandersetzen.

Ein mögliches Hilfsmittel zur passenden Besetzung bieten die Belbin Teamrol-

len (Abschn. 4.1.14.1). Dieses zeigt auf, welche Teamrollen wie besetzt sind. Der

Belbin Teambericht zeigt allfällige Defizite im Team auf und ermöglicht es, dass

sie ausgeglichen werden können. Dabei müssen auch die unterschiedlichen Er-

fahrungen fachlicher und methodischer Art zur Sprache kommen. Auf einen

Nenner gebracht: In der Auseinandersetzung mit der Unterschiedlichkeit liegt

das Steuerungspotenzial eines Teams!

Natürlich können mit der Zeit einseitige Hierarchiemuster entstehen, welche die Viel-

fältigkeit eines Teams schmälern. Dies geschieht besonders bei Teams, welche immer

wieder in derselben Zusammensetzung Projekte bearbeiten. Wenn Teammitglieder wich-

tige Informationen zurückhalten, leidet die Vielfalt ebenfalls. Derartige Verkrustungen

können nur mit Selbstreﬂexionen aufgebrochen werden. Die primäre Plattform hierfür ist

die vom Scrum Master moderierte Sprint Retrospektive. Hier wird die Zusammenarbeit

im Team kritisch reﬂektiert.

Selbstgesteuerte Teams sind keine Wohlfühloasen. Sie erwarten von ihren Mitgliedern

die vereinbarten Leistungen. Fremdkontrolle ist durch Selbstkontrolle abgelöst. Dadurch

kann ein entsprechender Gruppendruck entstehen, der im Extremfall zum Ausschluss ei-

nes Mitgliedes führen kann.

4.1.12.4

Wann ist Selbststeuerung sinnvoll?

Für Teams ist es wenig interessant, an Projekten zu arbeiten, bei denen es darum geht, eine

vorgegebene Lösung auszuarbeiten und zu realisieren. Sie setzen sich für IHRE Lösung

ein. Selbstgesteuerte Teams brauchen Gestaltungsfreiraum und müssen selber arbeiten

und entscheiden können. Somit kristallisieren sich Projekte oder Projektphasen mit offe-

nen Problemstellungen heraus, die mit Kreativität bewältigt werden.

Beispiel

Produktentwicklung, Erarbeitung von Geschäftsprozessen, Change-Projekte und Ge-

staltung einer Post Merger Integration sind für Selbststeuerung prädestiniert. Es sind

Projekte im Potenzial- und Pionierbereich (Abschn. 1.2.1). Dabei ist der Fokus auf

Business Value (Werte, Nutzen des Produktes) statt auf Detaillierung der Anforderun-

gen zu richten.

Projekte, die durch selbstgesteuerte Teams bearbeitet werden, müssen eine gewisse

Größe bzw. einen gewissen Ressourcenbedarf haben. Solche Projekte müssen konzentriert

4.1

Zusammenarbeit und Führung

373

innerhalb einer kurzen Zeitspanne abgewickelt werden können, damit sie nicht zerﬂed-

dern. Ein Projektteam, welches über die Koordination in die Stammorganisation einge-

bunden ist, erreicht diese Voraussetzungen nicht.

4.1.12.5

In eigener Kompetenz über Vorgehen und Lösungen entscheiden

Im klassischen Projektmanagement erarbeiten Projektteams Lösungsvorschläge und un-

terbreiten sie dem Auftraggeber oder dem Projektausschuss zum Entscheid. Selbststeue-

rung ist aber nur dann erfolgreich, wenn die Teams über die Lösung innerhalb eines

deﬁnierten Rahmens selber entscheiden können. Dies kann z. B. die Erarbeitung eines

internen Prozesses sein, welchen die Teammitglieder später selber „leben“ müssen. Oder

es handelt sich um eine Produktentwicklung, die das Team dem internen oder externen

Kunden anbietet, ohne die Genehmigung des internen Managements einzuholen. Dies vor

dem Hintergrund, dass die Teammitglieder in ihrem speziﬁschen Fachbereich über min-

destens so viel Wissen verfügen wie ihr Management. Sollte das Wissen im Team als

ungenügend erachtet werden, kann sich das Team auch jederzeit die Unterstützung durch

den Scrum Master oder andere Experten einholen. Durch Kunden- statt der Cheforientie-

rung erfährt das Team eine entsprechende Wertschätzung, ist es motiviert und übernimmt

die volle Verantwortung. Aber nicht nur über Lösungen, sondern auch über das Vorgehen

und die Methodenwahl soll das Team entscheiden können.

4.1.12.6

Müssen Mitglieder selbstgesteuerter Teams besonders ausgebildet

sein?

Das menschliche Verhalten wird sehr stark vom Kontext geprägt. So ist es auch beim Ver-

halten von Projektteams. Ist der Projektgegenstand für sie relevant und sinnvoll, haben sie

Autonomie, Verantwortung und Entscheidungsspielraum und wird ein Resultat erwartet,

so entwickeln Teams eine Qualität der Zusammenarbeit, welche diejenige „klassischer“

Projektteams übertrifft. Das zeigen jedenfalls bisherige Erfahrungen klar.

Freilich müssen Mitglieder von selbstgesteuerten Teams speziﬁsche Kompetenzen ha-

ben und Moderationstechniken, Problemlösungs- und Entscheidungsmethoden anwenden

und gut kommunizieren können. Eine Organisation muss sich auch dafür einsetzen, dass

diese Kompetenzen entwickelt werden können.

Es kann auch vorkommen, dass ein Team in Schwierigkeiten gerät. Wenn es den Kon-

ﬂikt nicht selber bewältigen kann, sind situative Interventionen wie Gruppenprozessana-

lysen oder die Konﬂiktbearbeitung mit Hilfe des Scrum Masters oder auch eines außenste-

henden Coaches notwendig. Diese Interventionen ermöglichen wertvolle Lernprozesse.

4.1.12.7

Kollegiale Führung innerhalb selbstgesteuerter Teams

Teamarbeit braucht Führung. In selbstgesteuerten Teams wird sie mit kollegialer Führung

(Deﬁnition Abschn. 4.1.2) situativ und verteilt wahrgenommen. Ein gut eingespieltes

Team ist in einem hohen Grad zur Selbststeuerung fähig. Die Vorteile sind: rasche An-

passung an Veränderungen, starkes Engagement und anhaltend hohe Identiﬁkation und

Motivation. Dies führt zu einem entsprechend großen Leistungsvermögen. Führung heißt

374

Team

hier einfach, dass Rollen, die bis anhin eine Führungskraft verkörperte, verteilt wahrge-

nommen werden. Das heißt, jemand übernimmt den Lead in einem Bereich, in dem er

besondere Fähigkeiten oder Kenntnisse hat.

Beispiel

Es ist sinnvoll, dass je eine Person mit entsprechenden Fähigkeiten und Interessen die

Moderation, eine andere die Organisation der Infrastruktur übernimmt, jemand auf die

Qualität achtet, ein weiteres Teammitglied den Teamzusammenhalt im Auge behält und

latente Konﬂikte anspricht usw. Wichtig ist es, über diese Führungs- bzw. Teamrollen

zu sprechen, sich zu organisieren und zu reﬂektieren. So kann vermieden werden, dass

die Rollen von einer einﬂussreichen Person monopolisiert werden, oder umgekehrt,

dass ein Führungsvakuum entsteht.

In permanenten Teams werden diese Führungsrollen meist an Personen festgeschrie-

ben, so dass jemand immer die Rolle des Gastgebers, des Moderators oder des Kommu-

nikators übernimmt. In Projektteams können sie aber durchaus abwechselnd wahrgenom-

men werden.

Das heißt aber nicht, dass Führung immer sanft wahrgenommen werden muss: Im

agilen Projektmanagement wird das Projektteam selber zum Unternehmer. Dieses „Basis-

unternehmertum“ bedeutet für alle involvierten Personen mehr Engagement und Verant-

wortung. Und weil durch die kurzen Sprint-Intervalle der Zeit- und Erwartungsdruck hoch

ist, können einzelne Teammitglieder durchaus in Stresssituationen geraten, vom Team kri-

tisiert oder sogar ausgeschlossen werden.

4.1.12.8

Vertrauen als Voraussetzung für selbstgesteuerte Teams

Besonders im agilen Projektmanagement ist Vertrauen (Abschn. 3.3.7) eine Vorausset-

zung, ohne die ein selbstgesteuertes Team nicht richtig arbeiten kann. Das Management

gewährt dem oder den Teams durch die Delegation von Entscheidungskompetenzen so-

zusagen einen Vertrauensvorschuss. Und dieses Vertrauen auf Vorschuss wird gemäß

bisherigen Erfahrungen viel weniger missbraucht als Pseudo-Vertrauen in einem Klima

von „Vertrauen ist gut, Kontrolle ist besser“. Im Gegenteil: Vertrauensvorschuss wird als

Wertschätzung aufgefasst und mit einem entsprechenden Einsatz honoriert.

Das Projektmanagement kann auch dem System vertrauen. Mit einer geeigneten Pro-

jektorganisation und vereinbarten Spielregeln können Rahmenbedingungen bereitgestellt

werden, die gewährleisten, dass sich die Teams selbstreferenziell voll engagieren und im

Sinne „ihres“ Unternehmens selbst unsichere Themen sicher bearbeiten. Bei komplexen

Vorhaben gibt es keine andere Wahl, als ein System zu entwickeln, dem man vertrauen

kann.

4.1.12.9

Indirekte Führung – Leadership neu definiert

Leadership heißt im agilen Bereich, die entsprechenden Bedingungen und das Klima

zu schaffen, damit Selbstführung möglich wird. Konkret: Delegation der Entscheidungs-

4.1

Zusammenarbeit und Führung

375

macht (Abschn. 4.1.8) innerhalb eines vom Management bestimmten Rahmens an das

Projektteam. Die Ermöglichung von Selbststeuerung ist kein Laisser-faire, sondern indi-

rekte Führung, also Führung nicht „im System“, sondern „am System“. Konkret ist damit

gemeint:

Klare Rahmenbedingungen schaffen, die einerseits Orientierung geben und anderer-

seits den Gestaltungsfreiraum deﬁnieren.

Inhaltlich: Was ist die Vision, die Zielrichtung, der Projektgegenstand und was nicht?

Prozessual: Welches sind die Spielregeln, was ist einzuhalten, und was ist verboten?

(Verbote können sehr gut den Freiraum deﬁnieren, denn alles andere ist gestattet.)

Im klassischen Projektmanagement entsprechen die Rahmenbedingungen dem Projekt-

auftrag, der seinerseits aber viel enger deﬁniert ist.

Weitgehende Entscheidungskompetenzen: Das Haus, welches das Team baut, be-

stimmt es selber. Damit übernimmt es auch die Verantwortung, dass das Haus zur Stadt

passt, also nicht quer zur Organisation steht.

Unterstützung, Coaching und Beratung anbieten, wenn sie gebraucht werden. Entwe-

der selber oder durch geeignete Berater.

Weitgehendes Vertrauen und absolut kein Hineinregieren in das Projektteam oder die

Teams.

Vorschussvertrauen führt nachweislich zu weniger Missbrauch als ein Klima des Miss-

trauens und der Kontrolle.

Interesse zeigen, Ergebnisse erwarten. Das ist Wertschätzung mit motivierender Wir-

kung, wenn jemand sich für die Teamarbeit und -Resultate interessiert und Feedback

zu erwarten ist.

Die Tab. 4.5 fasst beispielhaft Rahmenbedingungen zusammen, die Selbststeuerung

ermöglichen. Zu beachten ist, dass die prozessualen Regelungen ebenso wichtig sind wie

die inhaltlichen.

Es gibt indessen weitere Prinzipien, mit denen ein für Selbststeuerung günstiger Kon-

text geschaffen werden kann:

Transparenz und Öffentlichkeit: Transparenz ist eine Voraussetzung bei jeder Selbst-

steuerung, sei es in Projektteams oder in permanenten Organisationen. Transparenz

fördert Vertrauen und verhindert unliebsame Überraschungen. Transparenz wird durch

Vernetzung erreicht. Das heißt, ein selbstgesteuertes Team ist verpﬂichtet, sich über sei-

ne Aktivitäten, Zwischenergebnisse, Fragen usw. mit dem relevanten Umfeld (Auftrag-

geber, Projektausschuss, Kunde) auszutauschen. Auch innerhalb des Teams herrscht

Transparenz, z. B. bei der Offenlegung aller wichtigen Informationen, in der Sichtbar-

machung von Fortschritten, im Benennen von Problemen oder durch ehrliche Feed-

backs.

Einen Unterschied machen: Mit einer neuen Projektkultur kann die Führung einen

bewussten Unterschied zur Linienorganisation schaffen: Lass das Team in einem neu-

376

Team

Tab. 4.5 Rahmenbedingungen für Selbststeuerung

Leitplanken-Raster

Inhaltlich

– Produktvision und Zielsetzung: Was wollen wir, was wollen wir nicht erreichen?

Welcher Nutzen soll realisiert werden?

– Gesamtaufgabe: Welches ist der Projektgegenstand? Wie ist der Product Backlog

aufgebaut und strukturiert? Gibt es zu beachtende Prinzipien? Was gehört nicht

zur Aufgabe?

– Wie sieht die Release-Planung aus? Wie lange sollen die Sprints dauern?

– Welches Wissen ist für die Lösung der Aufgabe vorhanden? Welches Wissen

muss aufgebaut werden?

– Mit welchen Tools und Werkzeugen soll gearbeitet werden?

Prozessual

– Wie ist die Projektorganisation? Wer übernimmt welche Rollen?

– Wie setzen sich die Teams zusammen? Z. B. quer über die Hierarchien, keine

direkten Unterstellungen, interdisziplinär, mit Querdenkern?

– Zur Verfügung stehende Ressourcen

– Wie soll das Team bzw. wie sollen die Teams arbeiten? Z. B. organisieren sie

sich selbst, haben Entscheidungskompetenz und sind auch verantwortlich für die

erarbeitete Lösung?

– Wie wird kommuniziert? Z. B. auf Transparenz achten; Vernetzung mit dem Un-

terstützungsteam (= Steuergruppe, die nicht direkt eingreift, sondern unterstützt),

mit den anderen Teams, mit Kollegen usw.

– Was geschieht mit den Resultaten? Z. B. Präsentation und Auseinandersetzung

mit den betroffenen Bereichen und Kollegen.

artigen Kontext arbeiten, so kommt auch etwas Neuartiges – sprich Unkonventionelles,

Neues – heraus. Und umgekehrt: Selbstgesteuerte Teams sind „anders“. Sie werden

von den Kollegen im hierarchischen Kontext genau beobachtet. Das weckt Erwartun-

gen und kann stimulierend auf das Team wirken.

Einen Spannungsbogen bilden: Der Scrum-Ansatz macht es vor: fest terminierte

„Sprints“ bzw. Iterationen mit vereinbarten Resultaten. Verallgemeinert heißt das: Eine

Erwartungshaltung wird aufgebaut. Mit einer straffen Terminierung entsteht ein Span-

nungsbogen oder gleich mehrere. Am Ende dieses Bogens ist ein Meeting eingeplant,

an dem die Resultate oder Zwischenergebnisse einer möglichst breiten relevanten Öf-

fentlichkeit zur Diskussion unterbreitet werden. Je nach Projekt sind unterschiedliche

Iterationen sinnvoll. Beispielsweise dauern in einem Change-Projekt Änderungsitera-

tionen ca. zwei Monate, in einem Produktentwicklungsprojekt einige Wochen analog

zu Scrum. Derartige Zyklen, innerhalb deren konzentriert gearbeitet werden kann, hal-

ten die Spannung und die Energie hoch und ermöglichen permanente Feedback- bzw.

Lern-Schlaufen (Gellert und Nowak 2007).

Das alles ist nichts anderes als Führung über das System bzw. Gestaltung von Orga-

nisationsdynamiken und ist noch wenig in unserem Bewusstsein, gewinnt aber in agilen

Organisationen – und damit auch im agilen Projektmanagement – zusehends an Bedeu-

4.1

Zusammenarbeit und Führung

377

tung. Sie obliegt hauptsächlich dem Top-Management oder dem (internen) Auftraggeber,

teilweise zusammen mit den Projektverantwortlichen.

4.1.13

Spezifische Eigenschaften im klassischen Projekt

Welche speziﬁschen Kompetenzen, Eigenheiten oder Methoden sollen oder können be-

rücksichtigt werden in der Übernahme der Rolle als Projektleiter?

4.1.13.1

Grundsätze

Die speziﬁsche Anlage der Projektarbeit bedingt, dass der Projektleiter in seiner Rollen-

übernahme immer mehrere Ausprägungen der Führung (Abschn. 4.1.7) berücksichtigen

muss. Projekte führen und leiten umfasst sowohl die Zielerreichung (Sache) als auch die

Mitarbeiterführung. Der Projektleiter in der Rolle des „Managers“ führt das Projekt im be-

triebswirtschaftlichen Sinne. Er hat das Projektziel zu verfolgen, erstellt und führt einen

Ablaufprozessplan, koordiniert und überwacht den optimalen Einsatz der Ressourcen so-

wie die zur Verfügung gestellte Zeit und die ﬁnanziellen Mittel.

Zusätzlich übernimmt der Projektleiter in der Matrix-Projektorganisation und in der

reinen Projektorganisation die Rolle der operativen Leitung sowie die Führung seiner

Projektmitarbeiter. Viele Funktionen und Rollen sind in der normalen Linienführung und

in der Projektführung gleich. Für den Projektleiter resultieren daraus aber ein paar we-

sentliche Unterschiede:

Er übernimmt die Führungsaufgabe nur „auf Zeit“

Er hat keine oder nur unpräzise deﬁnierte Ressourcenkompetenz

Die formale hierarchische Eingliederung der Projektorganisation hat temporären Cha-

rakter

Die wichtigsten Werkzeuge sind:

präzise und vollständig deﬁnierte Projektziele

unterzeichneter Projektauftrag mit dem Auftraggeber

ein differenziertes Kommunikationskonzept

Klärung der Rollen und Regelung der A-K-V

vereinbarte Regeln der Zusammenarbeit mit den Projektmitarbeitern

Zum letzten Punkt gehört auch eine klare Transparenz über die vereinbarten Maßnah-

men und die möglichen Konsequenzen bei Nichteinhaltung der Vereinbarung (Eskalati-

onsvereinbarung) und zwar auf allen Stufen der Projekthierarchie.

4.1.13.2

Gewichtete Kompetenzprofile Projektleiter und Auftraggeber

Basierend auf dem Kompetenzmodell in Abschn. 3.1 zeigt Abb. 4.7 ein mögliches Kom-

petenzanforderungsproﬁl an Projektleiter und Auftraggeber.

378

Team

Auftraggeber

Projektleiter

Legende:

0 nicht relevant

1 nicht nötig

2 hilfreich

3 wichtig

4 Voraussetzung

Methoden-

kompetenz

Selbst-

kompetenz

Sozial-

kompetenz

Verhandlungs-

kompetenz

Fach-

kompetenz

Team- und

Führungs-

kompetenz

Methoden-

kompetenz

Selbst-

kompetenz

Sozial-

kompetenz

Verhandlungs-

kompetenz

Fach-

kompetenz

Team- und

Führungs-

kompetenz

Abb. 4.7 Gewichtete Kompetenzproﬁle im klassischen Projektmanagement

4.1.13.3

Führungsstile

Unter Führungsstil versteht man ein langfristig relativ stabiles, situationsvariantes Verhal-

tensmuster des Führenden (Lattmann).

Die eigentliche Mitarbeiterführung wird nur im klassischen Projektmanagement angewen-

det. Im Führungsalltag ist der Führungsstil die Art und Weise, wie die Führungstätigkeiten

Planung, Steuerung und Kontrolle durchgeführt und die einzelnen Führungsabläufe be-

einﬂusst werden. Ein bestimmter Führungsstil hat zur Folge, dass jede Führungssituation

durch ein einheitliches Grundverhalten gekennzeichnet ist. Auf der anderen Seite spielt

sich Führung immer auch in Beziehungen ab. Dies bedeutet, dass die an der Führung betei-

ligten Personen mit ihrer speziellen Situation die jeweilige Ausprägung des Führungsstils

beeinﬂussen.

Grundsätzlich wird der Erfolg des Projektes hauptsächlich am Nutzen gemessen, der

für die Organisation erreicht wurde. Wie dieser Erfolg zustande gekommen ist, wie der

Projektleiter seine Führungsaufgaben wahrgenommen hat, ist vorerst von sekundärer Be-

deutung. Gibt es den richtigen und Erfolg versprechenden Führungsstil? In Kap. 3 ist

ausgeführt, dass jeder Mensch durch eine einzigartige Konstellation von Grundbedürfnis-

sen und Fähigkeiten geprägt ist. Auch Organisationen, in welchen Projekte abgewickelt

4.1

Zusammenarbeit und Führung

379

Delegative Führung

Delegierte Entscheide an die Mitarbeiter

Autoritäre Führung

Alleinige Entscheidung der Führungsperson

gross

klein

gross

klein

autoritär

Führungsstile

delegativ

integrierend

partizipativ

Führungsperson erlaubt es dem Team

• das Problem zu identiﬁzieren

• die Optionen zu entwickeln

• über die Vorgehensweise zu bestimmen,

innerhalb der vorgegebenen Grenze

Abb. 4.8 Autoritäre und delegative Führung

werden, sind einzigartig und haben eine je eigene Organisationskultur. Deshalb kann es bei

den Führungsstilen kein Richtig oder Falsch geben. Vielmehr ist der optimale Führungsstil

für sich selber und für das Team zu ﬁnden, damit die Projektziele erreicht werden.

Autoritärer versus delegativer Führungsstil

Das von Tannenbaum und Schmidt entwickelte Führungskontinuum hat großen Nieder-

schlag gefunden in der Führungslehre (Abb. 4.8). Zwischen den beiden Polen der autori-

tären und der delegativen Führung sind unterschiedliche Ausprägungen möglich, welche

unterschiedliche Führungsstile ergeben. Die Führungsstile unterscheiden sich in Bezug

auf die Delegation von Entscheidungskompetenzen: Im partizipativen oder delegativen

Führungsstil sind diese teilweise oder vollständig an die Mitarbeitenden abgegeben. Dem

gegenüber steht der autoritäre Führungsstil: Hier verfügt der Vorgesetzte über sämtliche

Entscheidungskompetenz.

Dieses lineare Modell hat auch heute noch seinen Nutzen. So kann in einer Krise ganz

bewusst ein autoritärer Führungsstil zur Anwendung kommen. Die Notsituation recht-

fertigt schnelle Entscheidungen und klare Kompetenzzuteilungen. Oder am anderen Ende

der Skala kann für die Lösung eines schwierigen Problems die gesamte Entscheidungs-

kompetenz an ein Projektteam delegiert werden.

380

Team

niedrig

hoch

S 3 unterstützen

Partizipativer

Führungsstil

VG: Coach

MA: Könner

Ideen mitteilen und

ermutigen,

Entscheidungen

zu treffen

trainieren S 2

Integrierender

Führungsstil

VG: Trainer

MA: Lernender

Entscheidungen

erklären und

Gelegenheit zu

Fragen geben

delegieren S 4

Delegativer

Führungsstil

VG: Partner

MA: Experte

Verantwortung für

Entscheidungen

und Durchführung

übergeben

S 1 lenken

Autoritärer

Führungsstil

VG: Anweisender

MA: «Junior»

Genaue

Anweisungen

geben und die

Leistung überwachen

Sekundierendes Verhalten – Beziehungsorientierung

Dirigistisches Verhalten – Aufgabenorientierung

VG:

Vorgesetzter

MA:

Mitarbeiter

Abb. 4.9 Situatives Führungsmodell. (Basierend auf: Blanchard 2015)

Situatives Führungsmodell

Im situativen Führungsmodell orientiert sich der Führungsstil nicht nur an der aktuellen

Situation und an den zu erreichenden Zielen. Der wesentliche Referenzpunkt darin bil-

det der jeweilige Reifegrad der zu führenden Person. Er setzt sich zusammen aus dem

Produkt von Leistungsfähigkeit (Können) und Leistungsbereitschaft (Wollen), vergleiche

auch Abschn. 3.2. Diesem Reifegrad des Mitarbeiters (MA) wird dann, wie in Abb. 4.9

dargestellt, der Führungsstil des Vorgesetzten (VG) zugeordnet, welcher optimal zum Rei-

fegrad des Mitarbeiters passt: autoritär, integrierend, partizipativ und delegativ.

Ein großer Vorteil dieses Führungsmodells liegt darin, dass die Führungsperson der

Heterogenität des Teams gerecht werden kann. Vielfach ist es so, dass der persönliche

Reifegrad in einem Projektteam die ganze Spannbreite abdeckt zwischen sehr erfahrenen

Experten bis hin zu „Juniors“. In dieser Situation ist es nicht zielführend, wenn der Pro-

jektleiter nur einen Führungsstil anwendet. Vielmehr geht es darum, in der Beziehung mit

den jeweiligen Einzelpersonen den passenden Führungsstil zu ﬁnden.

Führungsstil S1: Anweisen, Dirigieren, Lenken

Der Vorgesetzte gibt präzise Anweisungen und beaufsichtigt gewissenhaft die Durch-

führung der Aufgabe.

4.1

Zusammenarbeit und Führung

381

Führungsstil S2: Trainieren, Überzeugen

Der Vorgesetzte lenkt und überwacht auch weiterhin gewissenhaft die Durchführung

der Aufgabe, bespricht aber seine Entscheidungen mit dem Mitarbeiter, bittet ihn auch

um Vorschläge, trainiert, unterweist und überzeugt den Mitarbeiter von der Notwen-

digkeit der Aufgabe.

Führungsstil S3: Beraten, Unterstützen

Der Vorgesetzte berät und unterstützt den Mitarbeiter, Lösungswege zu ﬁnden und Ent-

scheidungen zu treffen. Prinzip: Hilfe zur Selbsthilfe.

Führungsstil S4: Delegieren

Der Vorgesetzte delegiert dem Mitarbeiter in hohem Maße die Kompetenz und Verant-

wortung für die zu fällenden Entscheidungen und die zu lösenden Aufgaben.

Laterale Führung

Für die Führung ohne Weisungsbefugnis hat sich der Begriff laterale Führung etabliert

(Lat. Latus steht für „Seite“). Dieser Führungsstil ist v. a. in einer Projektkoordination prä-

destiniert, weil der „Projektleiter“ in dieser Projektorganisation keine Weisungsbefugnis

hat. Projektverantwortliche müssen also wirkungsvoll arbeiten können ohne institutionel-

le Macht. Der wesentliche Aufsetzpunkt dafür ist in der lateralen Führung die geliehene

Macht (Abschn. 4.1.3): Es geht darum, mit den Entscheidungsträgern der Linienorgani-

sation eine möglichst gute Abstimmung zu erreichen. Ein wesentlicher Erfolgsfaktor der

lateralen Führung ist das Festlegen von Rahmenbedingungen für das Umfeld (Organi-

sationsrahmen), den Projektleiter (Persönlicher Rahmen) sowie das Team (Teamrahmen)

(Radatz 2009). Folgende Fragestellungen sind dabei zu erarbeiten:

1. Organisationsrahmen

Durch die Klärung des Organisationsrahmens wird sichergestellt, dass die geliehene

Macht aus der Linienorganisation ihre Wirkung bestmöglich entfalten kann. Diese Punkte

muss der Projektleiter primär mit seinem Auftraggeber klären:

Welchen Nutzen möchte die Organisation im Idealfall aus dem Team- bzw. Projekter-

folg erzielen?

Was sind Tabus? Welche Themen sind kritisch?

Welche Grenzen gelten für die Projektarbeit? Ab wann gilt das Projekt als abgeschlos-

sen?

Wann und wo muss sich die Projektleitung mit wem abstimmen, um weder ins Leere

noch gegen den Willen der Organisation zu arbeiten?

Welche personellen und ﬁnanziellen Ressourcen stehen zur Verfügung? Wo verlaufen

die Grenzen?

2. Persönlicher Rahmen

Wer Verantwortung übernimmt, muss – um seine Handlungsfähigkeit zu beschützen –

auch festlegen, welche Regeln der Zusammenarbeit befolgt werden sollen. Zudem soll

382

Team

sich auch jede laterale Führungskraft bewusst machen, welche Ziele und Motive sie für

sich selber in dieser Aufgabe erreichen kann:

Was macht die Aufgabe persönlich attraktiv? Welche extrinsischen oder intrinsischen

Motivationsfaktoren können durch diese Aufgabe befriedigt werden? Aber auch: Was

soll oder darf nicht passieren?

Welche Anforderungen werden an das Team gestellt? Was braucht die Führungskraft

vom Team, damit die Aufgabe gut erfüllt werden kann? Wie sollen die Regeln der

Zusammenarbeit festgelegt werden?

Beispiel

In welcher Form wird kommuniziert?

Wie werden verbindliche Abmachungen getroffen?

Welche Konsequenzen haben nicht eingehaltene Termine?

Wie wird mit Absenzen und Verspätungen umgegangen?

3. Teamrahmen

Nicht nur der Auftraggeber, sondern auch die Linienvorgesetzten der ins Projekt dele-

gierten Mitarbeiter spielen durch das Leihen oder eben nicht Leihen ihrer Macht für die

laterale Führung eine wesentliche Rolle. Im Sinne der oben ausgeführten Machtverhält-

nisse werden die Projektmitarbeiter im Zweifelsfalle auf die Arbeiten den Fokus legen,

die für ihren Linienvorgesetzten Priorität haben.

Wer als laterale Führungskraft die Unterstützung der direkten Linienvorgesetzten nicht

hat, wird es schwer haben, seine Ziele zu erreichen. Aus diesem Grund empﬁehlt Sonja

Radatz, eine Sitzung durchzuführen mit allen Vorgesetzten des zukünftigen Projektteams,

in welcher simultan folgende Aspekte geklärt werden sollen:

Welchen Nutzen hat jeder einzelne Teamleiter aus dem angestrebten Projekterfolg

(monetär, Ansehen, ein wichtiger Schritt auf der Karriereleiter, Wissenszuwachs etc.)?

Wenn im Projekt kein subjektiv formulierter Nutzen für jeden einzelnen Linienvorge-

setzten deﬁniert werden kann, sind die Erfolgschancen für die laterale Führungskraft

resp. deren Projekt sehr gering. Ohne den konkretisierten Nutzen wird ein Linienvor-

gesetzter im Zweifelsfall bei Kapazitätsengpässen die Priorität auf andere Aktivitäten

legen.

Inwieweit bestehen Zielkonﬂikte zwischen den Aufgaben, die die zukünftigen Projekt-

teammitglieder im Rahmen ihrer Linienfunktion ausüben müssen, versus denjenigen,

welche in der Projektarbeit angestrebt werden sollen?

Wenn die Linienvorgesetzten die Abstimmung zwischen den Zielen und Prioritäten

ihrer Mitarbeiter nicht selber vornehmen, resultiert daraus ein Konﬂikt, den sie in das

System delegieren. Der Konﬂikt manifestiert sich damit als persönlicher oder sozialer

Konﬂikt.

4.1

Zusammenarbeit und Führung

383

Welche Zeitressourcen sind die einzelnen Vorgesetzten bereit, frei zu geben? Wo gibt

es Engpässe oder Grenzen, die schon jetzt vorhersehbar sind?

Wie wird damit umgegangen, wenn die Aufwände unterschätzt worden sind und nicht

mit den effektiv benötigten Ressourcen übereinstimmen?

Zudem müssen in diesem Gremium auch nochmals die mit dem Auftraggeber verhan-

delten Punkte zu den Grenzen und den Tabus geklärt werden.

Friktionspunkte in der lateralen Führung

Bei mangelndem Controlling oder schlechter Ressourcenauswahl besteht oft die Gefahr,

dass einzelne Personen überlastet sind oder Rollenkonﬂikte entstehen. Folgende Punkte

sollen helfen, Friktionen zu umgehen:

Die Erwartungen an einzelne Projektrollen frühzeitig und gemeinsam im Projektteam

bearbeiten. Dabei geht es um Klärung und Transparenz der unterschiedlichen Erwar-

tungen der Rollensender an den Rollenträger (Abschn. 4.1.10), aber auch um den

Kommunikationsprozess im Team.

Unterscheiden zwischen Rollen, die Individuen, und solchen, die das Projektteam oder

Teile davon (Teilprojektteams) wahrnehmen.

Rollendeﬁnitionen projektspeziﬁsch vornehmen, auch wenn einzelne Personen immer

wieder gleiche Projektrollen übernehmen.

Rollenvorgaben (Funktionsbeschreibung, Pﬂichtenhefte) an die jeweiligen Rolleninha-

ber und deren Stellvertreter richten.

Beispiel

Dinge, die ein Rollenträger (z. B. Projektleiter) . . .

tun muss (er muss das Projekt leiten und das Team führen),

tun soll (die Teammitglieder gleichwertig behandeln),

tun kann (etwas Gemeinsames außerhalb der Projektarbeit organisieren),

unterlassen soll, da es etwa mit seiner Rolle nicht vereinbar ist.

4.1.13.4

Führen über Ziele (Management by Objectives MbO)

Je nach Unternehmens- und Führungskultur wird die operative Umsetzung anders aus-

gestaltet. Eine weitverbreitete Führungstechnik ist MbO: Führung über Ziele. Projekt-

management bedeutet, Ziele zu erreichen. Es geht um das Projektziel. Innerhalb der Pro-

jektabwicklung bilden die Meilensteine immer Zwischenziele, die erreicht werden müs-

sen. Deshalb eignet sich MbO in der Projektarbeit gut. Diese Führungstechnik kommt

auch innerhalb der oben ausgeführten partizipativen und delegativen Führungsstile zur

Anwendung.

384

Team

Folgende Aspekte stehen bei der Führung über Ziele im Vordergrund:

Führen über Ziele (WAS) und nicht durch Lösungsstrategien (WIE).

Unternehmens- oder Projektziele müssen entlang der vertikalen Organisationsstruktur

heruntergebrochen werden.

Aufgabenerfüllungsprozess (A-K-V) basiert auf:

– Aufteilung der Aufgaben

– Delegation von Entscheidungs- und Weisungsbefugnis mit der dazugehörigen Ver-

antwortung.

Führen über Ziele bietet wesentliche Vorteile:

MbO fördert Leistungsmotivation, Eigeninitiative und Verantwortungsbereitschaft.

MbO erlaubt es, Aufgaben und inhaltliche Entscheide an die technischen Experten zu

delegieren, welche im Bereich ihrer Fachkompetenzen besser qualiﬁziert sind als der

Projektleiter, der mehr ein Generalist ist.

MbO schafft Freiräume in der Projektarbeit für situativ optimale Lösungen.

MbO beteiligt die Betroffenen, fördert und fordert.

MbO erlaubt es den Beteiligten, an den Aufgaben zu wachsen und ihre Qualiﬁkationen

zu erweitern.

MbO führt zu einer operativen Entlastung von Führungspersonen.

Mit MbO werden übergeordnete Ziele persönliche Ziele.

Ein wesentlicher Faktor, ob MbO erfolgreich sein kann oder nicht, ist das Grundver-

ständnis von MbO: Werden die gegenseitigen Erwartungen im Sinne einer Zielverein-

barung verhandelt und bei gegenseitiger Übereinstimmung vereinbart? Oder werden die

Ziele durch die Hierarchiestufen „top-down“ als Zielvorgaben angeordnet, ohne auf die

Meinungen und Bedürfnisse des Empfängers einzugehen? Tab. 4.6 macht die Unterschie-

de deutlich.

Das Führen über Zielvereinbarung ist natürlich zeitaufwändiger und es bedarf der Ver-

handlungskompetenzen beider Seiten. Aber nur durch einen Vereinbarungsprozess wird es

Tab. 4.6 Unterschiede zwischen Zielvorgabe und Zielvereinbarung

Zielvorgabe

Zielvereinbarung

Autoritär

Partizipativ

Verkaufskultur

Verhandlungskultur

Basiert auf Akzeptanz

Basiert auf Commitment/Identiﬁkation

Chef-orientiert

Chef- und Mitarbeiter-orientiert

Kurzdauernd/rasch

Längerer zeitlicher Prozess

Normale Anforderungen an Vorgesetzte

Hohe Anforderungen an Vorgesetzte

Oft Win-lose-Situation

Eher Win-win-Situation

Oft demotivierend

Motivierend

4.1

Zusammenarbeit und Führung

385

gelingen, ein wirklich hohes Commitment und damit verbunden auch eine hohe Motivati-

on und Verbindlichkeit bei den Personen zu erreichen, welche die Aufgaben übernehmen

sollen.

4.1.13.5

Schlüsselpositionen im Projektteam

Bei der Auswahl der Projektteammitglieder sind die folgenden Schlüsselpositionen zu

besetzen:

Projektleiter, Koordinator

Der Projektleiter stellt die Zusammenarbeit im Team sicher und sorgt dafür, dass alle Mit-

glieder des Projektteams die ihnen entsprechenden Funktionen und Rollen erhalten. Im

umfassendsten Sinne ist der Projektleiter der wichtigste Botschafter im ganzen Projekt-

team. Für diese Beziehungsarbeit muss er besonders fähig sein, Lobbying zu betreiben,

Unterstützung zu suchen, Entscheidungsträger in Kontakt zueinander zu bringen und zu

guten Absprachen motivieren.

Teammitarbeiter, Fachspezialisten

Alle wesentlichen Wissensbereiche, die zur Lösung der Problemstellung und zur Errei-

chung der Ziele erforderlich sind, müssen durch die Teammitglieder abgedeckt werden.

Die Mitglieder sind auf ihrem Fachgebiet ausgewiesene Spezialisten und gute Kenner der

betrieblichen Realität. Obwohl sie Insider sind, dürfen sie den Blick für das betriebliche

Umfeld nicht verloren haben. Sie sind informiert über die neuesten Entwicklungen auf ih-

rem Fachgebiet und wissen, falls sie nicht selber darüber verfügen, wo das entsprechende

Know-how bezogen werden kann.

Interdisziplinäre Zusammenarbeit setzt Offenheit und Respekt gegenüber andern Fach-

disziplinen voraus. Aus einem veränderten Blickwinkel entstehen neue „Wahrheiten“. Ein

Teammitarbeiter sollte kommunikationsfähig sein, d. h., dass er zuhören, sich aber auch

anderen mitteilen kann.

Projektteammitglieder sollen in der Lage sein, ihre Stammorganisation bzw. Interessen-

gruppe (Gewerkschaften, Benutzer, Frauen, Männer, Bevölkerung usw.) im Projektteam

würdig vertreten bzw. einbringen zu können. Mit zunehmendem Projektfortschritt wird

sich ihre Rolle erweitern. Nun können sie nicht mehr nur die Anliegen in das Projekt hin-

eintragen, sondern sie müssen immer mehr dazu beitragen, dass die erarbeiteten Lösungen

im Projektumfeld und in den jeweiligen Stammorganisationen verstanden und akzeptiert

werden.

Teamarbeit ist zeitweise spannungsgeladen und mit größeren Auseinandersetzungen

verbunden. Dazu gehört ein gesundes Maß an Selbstbewusstsein und Standfestigkeit, aber

auch Flexibilität und Anpassungsfähigkeit. Oft müssen an eigenen Ideen zugunsten eines

gemeinsamen Ganzen Abstriche in Kauf genommen werden. Ein Prozess, der für den

Einzelnen schmerzhaft und schwierig sein kann.

386

Team

Auftraggeber und Projektausschuss

Der Auftraggeber, evtl. ergänzt um die Mitglieder des Projektausschusses, hat gegen-

über dem Projektleiter die fachliche Weisungsbefugnis. Er muss in seiner Funktion in der

Stammhierarchie genügend hoch angesiedelt sein, um mit dem Projektleiter den Projekt-

auftrag aushandeln und ihm auch die benötigten ﬁnanziellen und personellen Ressourcen

bereitstellen zu können. Zudem wirkt er in seiner Hierarchiestufe als wichtiger Botschaf-

ter für das Projekt und ist verantwortlich dafür, dass dieses optimale Rahmenbedingungen

erhält zur Erfüllung des Projektauftrages.

4.1.13.6

Aspekte der Projektteamzusammensetzung

Zusätzlich zu den Schlüsselpositionen können folgende Aspekte für die Zusammenset-

zung des Projektteams relevant sein.

Wer stellt das Projektteam zusammen?

Ofﬁziell eingesetzt und nach Projektabschluss auch wieder aus der Verantwortung entlas-

sen wird das Projektteam vom Auftraggeber. Bei der Auswahl der Mitglieder muss der

Projektleiter aber entscheidenden Einﬂuss nehmen können. In allen Organisationen ist er

dabei auf die Mithilfe der Führungskräfte angewiesen. Damit diese die richtigen Personen

in die Projektteams entsenden können, müssen Auftraggeber und Projektleiter ein Anfor-

derungsproﬁl für die künftigen Projektteammitglieder formulieren.

Die Zielsetzung der Projektphase bestimmt die Teamgröße

Je nach Projektphase kann die Projektteamzusammensetzung wechseln. Für Machbar-

keitsstudien und Vorgehensplanung ist eine kleinere „Vordenker-Gruppe“ von Vorteil. Ist

dagegen eine möglichst breite Akzeptanz zu erreichen, so wird man sich eher für ein

großes, möglichst repräsentatives Team entscheiden.

Für die Projektleitung kann daraus ein Dilemma entstehen: Wenn alle betroffenen Krei-

se vertreten sein sollen oder der Auftraggeber ein Großteam zusammenstellt, ergibt das

viel zu große und zu schwerfällige Gruppen. In einem solchen Fall bewährt sich die Bil-

dung eines Projektleitungsteams (Kernteams), das die wesentliche Vorarbeit leistet, die

gegenseitige Koordination sicherstellt und diese dann dem „erweiterten Projektteam“ zur

Verarbeitung vorlegt.

Wechselnde Fähigkeiten sind gefragt

In den verschiedenen Projektphasen sind unterschiedliche Fähigkeiten erforderlich. So

sind während der Konzeptphase viel kreatives Denken und „Tüfteln“ notwendig, wogegen

in der Realisierungsphase Organisationstalent und Marketing-Know-how verlangt wer-

den. Unter Umständen sind diese Fähigkeiten nicht bei den gleichen Personen vorzuﬁn-

den, so dass es sinnvoll sein kann, die Projektteammitglieder im Verlauf der verschiedenen

Projektphasen auszuwechseln.

Beim Wechsel von Projektteammitgliedern sind die folgenden kritischen Punkte zu

beachten:

4.1

Zusammenarbeit und Führung

387

Zwischen den Teammitgliedern müssen sorgfältige und ausführliche Übergabearbeiten

stattﬁnden und protokolliert werden.

Darin muss geregelt werden, für welche Probleme die Vorgänger „haftbar“ sind und in

welchem Umfang sie den Nachfolgern bei der Lösung zur Verfügung stehen müssen.

Je nach Projektausprägung (Abschn. 1.2.1) sind verschiedene Fähigkeiten in unter-

schiedlicher Intensität notwendig. So wird ein Projekt mit ausgeprägtem Potenzial-Cha-

rakter eher innovative und kreative Freidenker benötigen, ein hochgradiges Akzeptanzpro-

jekt hingegen eher ausgezeichnete Kommunikatoren, die auf Menschen zugehen, ihnen

zuhören und mit ihnen Argumente für das Projekt ausarbeiten können.

Wer keine Zeit hat, soll’s besser sein lassen

Teammitglieder, die für das Projekt zu wenig Zeit aufwenden können oder möchten, blo-

ckieren oft die Zusammenarbeit und den Projektfortschritt. Ausgenommen davon sind

speziﬁsche Fachexperten mit punktuellen Aufgaben. Deshalb ist es wichtig, dass beim

Start geklärt wird,

mit wie viel Aufwand die Mitglieder zu rechnen haben und

ob sie im entsprechenden Umfang von ihrer üblichen Tätigkeit freigestellt werden.

Gegen zu viel Harmonie im Team

Jeder Projektleiter wünscht sich, dass in seinem Projektteam die „Chemie“ stimmt und

man harmonisch zusammenarbeiten kann. Dieser Wunsch ist verständlich, aber nicht im-

mer sinnvoll. Spannungen, die sich aus der Problemstellung ergeben oder aus gegensätzli-

chen Interessenlagen verschiedener Organisationseinheiten entstehen, sind grundsätzlich

nicht etwas Schlechtes. Sie können im Gegenteil im Projektteam als Chance für eine Klä-

rung genutzt werden.

Probleme, die während der Projektbearbeitung umgangen oder auf die lange Bank ge-

schoben werden, holen einen später in viel dramatischerer Weise wieder ein. Dramatisch

deshalb, weil mit zunehmendem Projektfortschritt der ﬁnanzielle und zeitliche Anpas-

sungsaufwand überproportional zunimmt, um solche „Fehler“ zu korrigieren.

Wir Autoren empfehlen Projektleitern:Sparen Sie Ihr Harmoniebedürfnisfür den

Feierabend auf und holen Sie Kritiker und Querdenker in Ihre Teams. Fordern

Sie frischen Wind und Realitätsnähe in der Projektarbeit! Dabei ist zu bedenken,

dass Sie sich und die anderen Projektteammitglieder damit nicht überfordern.

Wenn das richtige Maß fehlt, wird die Arbeit zu stark blockiert. Anstelle von Ge-

winnern resultieren Verlierer.

388

Team

4.1.14

Einflussfaktoren für die erfolgreiche Zusammenarbeit

Projekte sind durch Einzelleistungen nicht zu bewältigen. Jeder Auftraggeber muss für

sein Projekt ein Team zusammenstellen können, welches die Herausforderungen gemein-

sam erfolgreich meistert. Deshalb ist es wichtig für die Projektverantwortlichen, den

Teamerfolg nicht dem Zufall zu überlassen, sondern unterschiedliche Einﬂussfaktoren

zu kennen und zu nutzen, die auf die Zusammenarbeit in Teams einen positiven Einﬂuss

haben.

4.1.14.1

Belbin Teamrollen

In Abschn. 4.1.10 wird ausgeführt, wie wichtig klar deﬁnierte und vereinbarte Rollen

für die Projektarbeit sind. Dieser Deﬁnitionsprozess kann durch die Belbin Teamrollen

sehr gut unterstützt werden. In Abschn. 3.10.2.1 ist das Konzept der Belbin Teamrollen

grundsätzlich vorgestellt. In diesem Abschnitt geht es darum, dieses als Erfolgsfaktor der

Zusammenarbeit zu nutzen.

Nicht erfolgreiche Teams: Unausgeglichen in den Teamrollen

In den Management-Spielen von Belbin hätte erwartet werden können, dass die Teams,

welche sich aus den Menschen mit dem höchsten Intellekt zusammensetzten, auch am bes-

ten abschnitten. Aber das bestätigte sich in diesem Experiment nicht. Diejenigen Teams,

welche über den höchsten individuellen Intellekt verfügten, konnten ihr Potenzial nicht

ausschöpfen und waren von Rollenkonﬂikten gebeutelt (Bergander 2008).

Erfolgreiche Teams: Optimale Balance der Teamrollen

Am erfolgreichsten sind nach Belbin diejenigen Teams, die in den Teamrollen optimal

ausgeglichen sind: Es wäre ein großer Verlust für das Team, wenn ein starker Macher

seine Qualitäten nicht mehr einbringen würde aus Angst, andere Personen zu verletzen.

Viel besser ist es, wenn diesem starken Macher ein starker Teamarbeiter zur Seite ge-

stellt wird, der sich für eine gute Teamatmosphäre einsetzt und dem das Wohlbeﬁnden im

Team ein wichtiges Anliegen ist. Dieser Teamarbeiter hat sehr hohe kommunikative Kom-

petenzen, kann somit gut zuhören und vermitteln. Auch auf die Talente des Wegbereiters

kann kein Projektteam verzichten. Seine Beiträge zur Vernetzung und Kommunikation

sind wichtig. Aber er braucht einen Umsetzer, der die Ideen und Möglichkeiten wirk-

lich konkretisieren kann, ebenso einen Perfektionisten, der zuverlässig und gewissenhaft

Aufgaben von hoher Komplexität übernehmen kann. Es ist also der Verbund der unter-

schiedlichen Verhaltens-Cluster (Teamrollen), welcher es den Einzelnen erlaubt, sich mit

ihren Stärken einzubringen, der gleichzeitig sicherstellt, dass die jeweiligen Schwächen

durch die Stärken einer anderen Teamrolle wieder ausgeglichen werden.

Belbin Teambericht

Um diese Ausprägungen im gesamten Projektteam je Teamrolle zu erfassen, werden die

individuellen Teamrollen in einen Teambericht zusammengefasst. In Abb. 4.10 werden

4.1

Zusammenarbeit und Führung

389

MA = Mitarbeiter

MA 1

MA 2

MA 3

MA 4

Neuer MA

Abb. 4.10 Belbin Kompetenzgruppen. (Belbin Deutschland e.K./Bergander 2008)

die verschiedenen Mitarbeiter ihren am stärksten ausgeprägten Teamrollen zugeordnet. In

Bezug auf die Kompetenzgruppen bedeutet das:

Erledigen (Macher, Perfektionist, Umsetzer): Gut vertreten

Denken (Spezialist, Neuerer, Beobachter): Gut vertreten

Kommunizieren (Teamarbeiter, Koordinator und Wegbereiter): Nicht vertreten

Der Projektverantwortliche, der diesen Teambericht sieht, kann nun die aktuellen

Schwächen des Teams sofort erkennen. Im Bereich der internen und externen Kommu-

nikation werden in diesem Beispiel die Schwachstellen sein: Stakeholder-Management,

Konﬂiktmanagement oder auch die Abstimmung unter den Teammitgliedern werden mit

hoher Wahrscheinlichkeit vernachlässigt.

Blinder Fleck im Team

So wie jeder Mensch hat auch jedes Team einen blinden Fleck (Abschn. 3.9.7.1). Das ist

oft dadurch bedingt, dass sich Gleich und Gleich gerne verbindet: Wenn es darum geht,

ein Team zusammenzustellen, spielen Beziehung und Sympathie zu anderen Personen

eine wichtige Rolle. Wer ein starker Macher ist oder ein ausgeprägter Perfektionist, hat

390

Team

meistens mehr Sympathien zu seinesgleichen als zum konträren Gegenüber. Ist der

Projektleiter ein Macher, so ist die Wahrscheinlichkeit hoch, dass er intuitiv eher Leu-

te in sein Team holt, die seinen Werten und Kompetenzen entsprechen. Diese werden

höchstwahrscheinlich der Kompetenzgruppe „Erledigen“ angehören. Für einen Macher

sind Sitzungen oder Kundenbesuche oft verschwendete Zeit. Die Aktion steht für ihn im

Vordergrund, während die Reﬂexion für ausgewogene Lösungsansätze (Denken) oder die

gut abgestimmte Kommunikation eher im Hintergrund steht. Dadurch entsteht ein Team,

welches in seinen Teamrollen unausgeglichen ist.

Was dem Team meist nicht bewusst ist, wird einer außenstehenden Person relativ

schnell klar, wenn sie darauf schaut, wie die Zusammenarbeit läuft, welche Arbeiten mit

welcher Priorität angegangen werden und welches Verhalten im Team belohnt oder sank-

tioniert wird. Somit hat auch jedes Team einen blinden Fleck, den es bewusst zu machen

gilt.

Unbewusste Ergänzung der Teamrollen

Wenn nun per Zufall ein starker Teamarbeiter in das Team käme, was würde dann mit

dieser Person passieren (Neuer MA Abb. 4.10)? Wahrscheinlich hätte diese Person einen

schweren Stand, weil sie nicht dem Selbstverständnis der Kompetenzgruppen „Erledigen“

und „Denken“ entspricht. Die Gefahr besteht, dass diese Person zum Ventil und der Pro-

jektionsﬂäche der Gruppe wird, weil sie durch ihre Andersartigkeit das aktuelle Gefüge

der Gruppe bedroht. Wenn diese Person also eine Aussprache möchte zu einer Konﬂiktsi-

tuation oder es ihr ein Anliegen wäre, die Regeln der Zusammenarbeit zu klären, wie es

im „Norming“ auch gemacht wird (Abschn. 4.2.3) dann besteht die Möglichkeit, dass ihre

Bedürfnisse nicht ernst genommen werden unter Begründungen wie: „. . . dafür haben wir

keine Zeit“, „wir müssen vorwärtskommen, nicht plaudern“.

Bewusste Ergänzung der Teamrollen

Ganz anders wäre die Situation, wenn sich der Projektleiter oder dem Team bewusst ist,

dass in den Teamrollen ein starkes Ungleichgewicht besteht und aktiv nach einer Person

gesucht würde, welche die brachliegende Kompetenzgruppe abdeckt. Den Beteiligten wie

auch der neuen Person wäre von Anfang an klar, dass sie eine Außenseiterrolle einnimmt

und gerade in dieser Andersartigkeit einen ganz wesentlichen Beitrag zu leisten hat für

das Team. Dass die neue Person damit in einer ersten Phase auch Irritation oder sogar

Widerstand auslösen wird, ist allen klar. Aber sie wird damit ganz anders umgehen, als

wenn die Teamrolle unbewusst ergänzt worden wäre.

Kommunikation, Konﬂiktmanagement und Verhandlungen

In diesen Ausführungen wird bewusst, dass das hohe Ideal von ausgeglichenen Team-

rollen in einem Projekt nur dann erreicht werden kann, wenn deren Nebenwirkungen

bewusst integriert werden: Wer alle Teamrollen besetzt, hat damit Menschen mit ganz

unterschiedlichen Charaktereigenschaften, Werten und Erwartungen im Team. Das wird

4.1

Zusammenarbeit und Führung

391

zwangsläuﬁg zu unterschiedlichen Überzeugungen führen, was als Konsequenz wiederum

bedeutet: intensive Debatten, Streit und auch Konﬂikte.

Ein erfolgreiches, leistungsfähiges Team kann also keine „Wohlfühl-Oase“ sein. Viel-

mehr sind es gerade Debatten, Streit und Konﬂikte, welche immer wieder neu eine

Balance herstellen zwischen den positiven und negativen Eigenschaften der verschiedenen

Teamrollen. Damit das möglich ist, muss die Beziehungsebene in der Zusammenarbeit

(Abschn. 1.5) gut entwickelt sein. Dies bedeutet: hohe Kompetenzen der involvier-

ten Personen im Bereich der persönlichen Kommunikation (Abschn. 3.9), Rollenklä-

rung (Abschn. 4.1.10), Verhandlungsführung (Abschn. 4.3) und Konﬂiktmanagement

(Abschn. 4.4).

4.1.14.2

Projektkultur

In Abschn. 3.4.1 ist das Thema der kulturellen Prägung beschrieben. Nun wird der Fokus

auf die speziﬁsche Projektkultur gelegt. Diese unterscheidet sich mehr oder weniger von

der Kultur der Stammorganisation. So gelten hier zum Teil andere Spielregeln, Prinzipien

und Werte bzw. Arten der Problemlösung als im Tagesgeschäft. Während in der Stamm-

organisation diese Kultur prägenden Elemente etabliert und nur schwer zu verändern sind,

können sie in der Suborganisation Projekt neu proirisiert, vereinbart und gelebt werden.

Man spricht dann von Subkultur.

Beispiel

Kulturprägende Elemente können sein:

Anbindung der Projektorganisation an die Stammorganisation (Abschn. 2.3.9.8).

Projektmanagement-Ansatz: agil, klassisch oder hybrid.

Führungsstil: von autoritär bis delegativ (Abschn. 4.1.13.2) oder kollegiale Führung

mit Selbststeuerung (Abschn. 4.1.12.7).

Persönliche Kommunikation (Abschn. 3.9) mit Aspekten wie „Ich- oder Du-Bot-

schaft“ oder dem Umgang mit Feedback.

Informations- und Kommunikationskonzept Abschn. 2.4.10 sowie Stakeholder-Ma-

nagement mit der formellen und informellen Kommunikation (Abschn. 2.3.5).

Deﬁnition des Gestaltungsspielraums und Festlegung der Entscheidungskompeten-

zen (A-K-V Abschn. 4.1.5).

Fehlerkultur und Umgang mit dem Scheitern (Abschn. 3.8.5).

Kreation des Projektnamens und Projektlogos.

Je nach Projektart können sich diese Elemente mehr oder weniger von der Stammorga-

nisation abheben. Je komplexer, je neuartiger ein Projekt ist, desto ausgeprägter wird sich

die Projektkultur von der Linienkultur unterscheiden. So ist die Kultur eines Standard-

projektes derjenigen der Stammorganisation in der Regel ähnlicher als diejenige eines

Potenzial- oder Pionierprojektes (Abschn. 1.2.1). Und umgekehrt: In einem speziellen

Projekt kann das Verhalten der Akteure durch eine besondere Kultur animiert werden.

392

Team

In einem Projektrahmen, der herausfordert, können auch herausragende Ergebnisse ent-

stehen.

Kulturgestaltung beeinﬂusst somit das Verhalten und ist indirekte Führung. Nur: die

Kulturdifferenz muss im Unternehmen vom Management gewollt sein und kommuni-

ziert werden, sonst kann das Projekt abgestoßen, d. h. nicht ernst genommen werden.

Kulturprägende Elemente müssen indessen nicht nur gewollt und formuliert, sondern

auch gelebt werden, was gerade am Anfang des Projektes eine große Herausforderung für

die Projektverantwortlichen ist. Da bietet sich der Startworkshop oder Kick-off an, an dem

die neuen Prinzipien und Regelungen vereinbart und eingespielt werden.

Neuartige Projektkulturen können auch eine wertvolle Erfahrung für zukünftige per-

manente Organisationen sein. So sind Scrum-Projekte Vorläufer für selbstgesteuerte Or-

ganisationen.

Was nicht funktioniert, sind eigentliche Kulturprojekte, also Projekte, bei denen die

Kultur des Unternehmens verändert werden soll. Projekte müssen immer einen „harten“

Projektgegenstand beinhalten. Die Kultur ist mitlaufend. Aber bei Change-Projekten

(Abschn. 1.4.4) ist es möglich, eine sich vorgestellte zukünftige Kultur im Projekt bereits

vorwegzunehmen und bei der Bearbeitung mitlaufend zu erleben und auszuprobieren.

4.1.14.3

Radical Collaboration

In der Projektarbeit wird die wirkungsvolle Zusammenarbeit der Teams immer mehr zur

Match entscheidenden Funktion, denn die technischen Probleme und der entsprechen-

de Informationsaustausch sind lösbar. Vor allem auch in zeitkritischen Projekten sind

hierarchie- und konkurrenzfreie Zusammenarbeitsformen nötig. Die Basis dazu sind

Zusammenarbeitskulturen mit vertrauensbasierten Arbeitsbeziehungen sowie hoher Rol-

lenﬂexibilität der Individuen innerhalb des Projektes, der Abteilungen oder Organisatio-

nen. Den Anforderungen entsprechend sind dadurch neue Teamkonstellationen schnell

möglich. Es zählen vor allem die Efﬁzienz, Produktivität, Innovationskraft und Agilität

des Teams. Mit der Methode Radical Collaboration wird die Balance in diesen wech-

selnden Situationen am besten hergestellt. Das Prinzip dieses Ansatzes ist in Abb. 4.11

dargestellt. Die Frage ist, woran sich die Teammitglieder orientieren: An den eigenen Be-

dürfnissen oder an der Optimierung der Bedürfnisse der Gesamtgruppe? Wer sich nur

an seinen eigenen Bedürfnissen orientiert, hält sich in der „Red Zone“ auf. Daraus wird

ersichtlich, dass dieses Verhalten aus einer Team-Perspektive nicht zielführend ist. Das

Gegenteil wäre die Unterordnung der eigenen Bedürfnisse unter diejenigen der Kollegen.

Das hat zwar einen beruhigenden Effekt für die Gruppe, führt aber möglicherweise dazu,

dass die sich unterordnende Person die Gruppe nicht positiv unterstützt mit ihren Ideen

und Fähigkeiten. Deshalb ist es nicht effektiv und wird als die „Pink Zone“ (aus dem

Englischen für Parkverbotszone) bezeichnet. Das Optimum wird erreicht, wenn es den

Teammitgliedern gelingt, sich an den eigenen und fremden Bedürfnissen zu orientieren,

mit Fordern und Fördern den gemeinsamen Erfolg zu unterstützen („Green Zone“).

Dies bedeutet aber oftmals, wesentliche bisherige Zielsetzungen des eigenen Erfolges

neu zu deﬁnieren, also auch bisher als stark und eigenständig geltende Stärken und Attri-

4.1

Zusammenarbeit und Führung

393

Unterordnung

Pink

Zone

Green

Zone

Red

Zone

Orientierung an meinen Bedürfnissen

Orientierung an den Bedürfnissen des anderen

Abb. 4.11 Typologie des Individualverhaltens in Teams. (Abgeleitet aus einer Idee von www.

euforia.org, 2018)

Tab. 4.7 Transformation des Mindset

Red-Zone-Verhalten

Green-Zone-Verhalten

Weg von ...

– gewinnen

– absichern

– nicht Verlieren

– Kampfhaltung

– Recht haben

– nicht Blamieren

– Risiko vermeiden

– extrinsischer Motivation

– Arbeit ist mühsam, unangenehm

Hin zu ...

– Erfolg

– wachsen

– verbinden

– aufrichtig und freimütig

– kollaborieren

– Achtsamkeit

– Risiko eingehen

– intrinsischer Motivation

– Arbeit ist angenehm, lustvoll

bute neu zu deuten. Es erfordert ein anderes Denken und eine entsprechende Einstellung.

Radical Collaboration erfordert somit allenfalls einen anderen Mindset. Tab. 4.7 stellt die

Verhalten der „Red Zone“ und der „Green Zone“ einander gegenüber.

Der Ansatz der Radical Collaboration entstand in den achtziger Jahren in Kalifornien

und wurde vom Richter Jim Tamm initiiert. Die Firmen Bosch, Toyota, Nasa und vie-

394

Team

le andere internationale Konzerne richten Teile ihrer Organisationen heute entsprechend

neu aus. Dies sind vor allem Bereiche, in denen Innovation, technische Entwicklungen

und Kundenanforderungen gemeinsam und bereichsübergreifend zu realisieren sind. Die

Teamstrukturen orientieren sich primär an den Aufgaben und den Kompetenzen der Team-

mitglieder und nicht – wie bisher – an den Organisationsstrukturen und Hierarchien. Basis

des Ansatzes sind fünf zentrale Kernkompetenzen (Tamm und Luyet 2005):

1. Kollaborative Absicht: Persönlicher Erfolg ist nicht die Maxime. Der Fokus liegt auf

gemeinsamen Vorteilen und gemeinsamem Erfolg.

2. Aufrichtigkeit: Aufbau einer ehrlichen und offenen Beziehung, in der sich das Indivi-

duum sicher genug fühlt, auch schwierige Themen ansprechen zu können.

3. Selbstverantwortung für das eigene Tun und Handeln.

4. Selbstbewusstsein: Sich selbst und andere gut genug kennen, um schwierige zwischen-

menschliche Probleme einzuordnen und Probleme zu lösen, auch in neuen Konstella-

tionen.

5. Problemlösung und Verhandlung: Anstehende Konﬂikte verhandeln und die einzel-

nen Interessen herausarbeiten. Gestärkt aus geklärten Beziehungen agieren können.

Radical Collaboration beschreibt somit nur die grundlegenden Team- und Führungs-

voraussetzungen, welche notwendig sind, damit das Konzept der kollegialen Führung und

der Selbststeuerung im agilen Ansatz funktionieren kann. Natürlich leistet die Radical

Collaboration auch einen wertvollen Beitrag im klassischen Projektmanagement.

4.1.14.4

Multikulturelle Zusammenarbeit

Globalisierung fordert multikulturelle Projektteams

Multikulturelle Projektteams sind heute die Regel und nicht mehr die Ausnahme. In dieser

Arbeitsanlage prallen unterschiedliche kulturelle Prägungen aufeinander (Abschn. 3.4).

Dies stellt an die Gestaltung der Beziehung in der Zusammenarbeit zusätzliche Anfor-

derungen (Abschn. 1.5): In jedem Kontakt erleben wir uns in Gemeinsamkeiten und in

Unterschieden, sei es in Bezug auf die verbale oder non-verbale Kommunikation, unser

Verhalten in Konﬂiktsituationen oder unter Stress, oder in den Strategien der Problemlö-

sung.

Aufgrund von unserer eigenen kulturellen Prägung, unseres Wertesystems und

Menschen- resp. Weltbildes generieren wir bewusste und unbewusste Erwartungen

an unsere Umwelt und an unsere Mitmenschen. Wenn wir da mit einem Unterschied

konfrontiert sind, weil ein Mensch ein anderes Verhalten zeigt als jenes, welches wir

erwarten würden, reagieren wir irritiert. Genau dies passiert in der multikulturellen Zu-

sammenarbeit. Hier sind wir immer wieder neu mit Verhaltensweisen anderer Menschen

konfrontiert, die für uns ungewohnt und unerwartet sind.

Natürlich sind nicht nur die Projektteams multikulturell, sondern auch die Märkte und

die Kunden. Die allerwenigsten Firmen können noch von einem monokulturellen Kunden-

4.1

Zusammenarbeit und Führung

395

Tab. 4.8 Monochrone und polychrone Planungsstile

Monochron

Polychron

Bevorzugt es, eins nach dem anderen zu ma-

chen

Fühlt sich gut, mehrere Projekte gleichzeitig zu

bearbeiten

Ist fokussiert auf exakte Planung. Vermeidet

Unterbrechungen

Ist gut im Improvisieren, lebt mit ständigen

Unterbrechungen

Glaubt an Zahlen und Fakten

Jongliert mit Zahlen und Fakten

Pünktlichkeit und Termine werden ernst ge-

nommen

Pünktlichkeit und Termine werden ﬂexibel

gehandhabt

Regeln werden beachtet

Regeln werden umgangen

Sache vor Beziehung

Beziehung vor Sache

stamm leben. Es geht darum, in interregionalen oder internationalen Märkten und damit

auch in unterschiedlichen Kulturen erfolgreich sein zu können. Projektorganisationen, die

zu einer konstruktiven multikulturellen Zusammenarbeit nicht fähig sind, werden auch

nicht in der Lage sein, mittel- und langfristig an den immer stärker vernetzten Märk-

ten teilzuhaben. Damit muss die multikulturelle Zusammenarbeit nicht als Hemmnis oder

Problemquelle gesehen werden, sondern als absolute Grundvoraussetzung für den zukünf-

tigen Erfolg.

Monochrone und polychrone Organisationskulturen

(Organisations-)Kulturen können über unterschiedliche Kategorien differenziert werden.

Ein Ansatz liegt in der Unterscheidung der Planungs- und Organisationsstile. In den Ex-

tremen können diese tendenziell nach monochronen oder polychronen Kriterien geprägt

sein. Die Tab. 4.8 stellt die beiden Ansätze einander gegenüber (Zaninelli 2005).

Natürlich handelt es sich dabei um Extreme der monochronen und polychronen Aus-

prägungen. Aber die Unterschiede haben, je nach Ausprägung, einen wesentlichen Ein-

ﬂuss auf die Zusammenarbeit. Mittel- und Nordeuropa und die angelsächsischen Kulturen

werden eher dem monochronen Planungs- und Organisationsstil zugeordnet. Der romani-

sche, hispanische und von der Tendenz her auch der russische und arabische Kulturraum

sind dagegen stärker durch den polychronen Arbeitsstil beeinﬂusst.

Beispiel

Was bedeuten diese Unterschiede für die Projektarbeit? Je mehr die Mitglieder einer

Projektorganisation polychron geprägt sind, desto wichtiger ist es, in die Entwicklung

der Beziehungsebene zu investieren resp. dieser Raum zu lassen. Polychron bedeutet

nicht, dass der Arbeitsinhalt nicht relevant sei. Vielmehr geht es darum, dass zuerst ein

Bezug und eine Vertrauensebene entwickelt werden müssen, bevor man sich der Sa-

che widmen kann. Während die monochrone Kultur in Regeln einen Nutzen sieht und

diese auch beachtet, werden diese im polychronen Ansatz eher hintergangen. Auch die

Pünktlichkeit an Sitzungen und das Einhalten von Terminen können oft ein Zankapfel

werden: Monochron werden diese ernst genommen, polychron eher als Referenzpunkt

beachtet.

396

Team

Ziel

Start

Monochron

Wahrheit

Wirklichkeit

Ziel

Polychron

Start

Abb. 4.12 Monochrone und polychrone Kultur

In Abb. 4.12 sind die Unterschiede zwischen den beiden Planungsstilen graﬁsch darge-

stellt. Die monochrone Kultur ist geprägt durch ein strukturiertes, sequenzielles Vorgehen.

Demgegenüber ist die polychorone Organisationsform sehr viel mehr „agil“ unterwegs

und passt seine Vorgehensweise immer wieder der aktuellen Situation an. Die Darstel-

lung lässt sich gut in einen Bezug setzen zum mechanistischen und systemischen Weltbild

in Abschn. 1.6.4: Monochron ist eher mechanistisch geprägt und orientiert sich an der

„Wahrheit“, während polychron eher systemisch geprägt ist und sich an der konstruierten

„Wirklichkeit“ orientiert.

Chancen und Gefahren monochroner und polychroner Organisationskulturen

Die meisten von uns fühlen sich mit der einen oder anderen Ausprägung mehr vertraut.

Und damit verbunden ist wohl auch die Überzeugung, welche Ausprägung die bessere ist.

Oben ist ausgeführt, dass beiden Kulturen große geograﬁsche Gebiete und Wirtschaftsräu-

me zugeordnet werden. Das bedeutet für alle international ausgerichteten Unternehmen,

dass sie zumindest mit unterschiedlichen Kulturen bei ihren Kunden umgehen können

müssen. Oft werden sie, um wirklich erfolgreich sein zu können, die kulturelle Prägung

eines Zielmarktes – zumindest zum Teil – auch verinnerlichen müssen. Damit kann man

nicht im „Entweder-oder“ verharren, sondern es gilt, das „Sowohl-als-auch“ zu erschlie-

4.1

Zusammenarbeit und Führung

397

Tab. 4.9 Chancen und Gefahren monochroner/polychroner Organisationskulturen

Monochron

Polychron

Chancen

Zuverlässig in Bezug auf Sachverhalte

Zuverlässig in Bezug auf Beziehungen

Reibungslose Abläufe

Flexibles Sich-Einstellen auf veränderte

Bedingungen und Störfaktoren

Gut im Erstellen und Durchführen von

Plänen

Gut im Jonglieren von Unerwartetem

Gefahren

Wenig Kontakt zu einer sich vielleicht

verändernden Realität

Kann durch ständiges Einbeziehen sich

ändernder Umstände chaotisch sein

Im Extremfall starr und unﬂexibel

Projekte können versanden

Kann zur Vernachlässigung der Bezie-

hungsebene führen

Zeit und Termine schwer kalkulierbar

ßen, wie unten noch detaillierter ausgeführt ist. Beide Ansätze bergen Chancen und Ge-

fahren, wie Tab. 4.9 darstellt (Zaninelli 2005).

Haltung und Einstellung

Für Gruppen oder Menschen, welche die Extreme leben, bergen diese unterschiedlichen

Ausprägungen auch ein wesentliches Konﬂiktpotenzial. Damit Zusammenarbeit gelingen

kann, müssen alle involvierten Personen gegenüber anderen Kulturen eine offene Grund-

haltung entwickeln, die es ihnen erlaubt, auch bei ungewohntem Verhalten des Gegenübers

Wertschätzung zu zeigen. Dies kann gelingen, wenn in der Kommunikation zwischen

Wirkung und Wertung unterschieden wird. Wer verbale oder non-verbale Signale als

Wertung seiner selbst oder einer Situation wahrnimmt, fühlt sich schnell angegriffen oder

verletzt, was dann zu Konﬂikten eskalieren kann. Deshalb brauchen multikulturelle Pro-

jektteams auch hohe Kompetenzen in Bezug auf das Konﬂiktmanagement.

Schließlich müssen die involvierten Personen auch hier in der Lage sein, sich in ihrem

Denken aus einer Haltung des „Entweder-oder“ in die des „Sowohl-als-auch“ zu entwi-

ckeln. Die Komplexität und die Dynamik, in welcher sich Projektteams bewegen, lassen

es nicht mehr zu, dass die Arbeit mit starren Denkmustern, Normen und Vorgaben bewäl-

tigt werden kann. Vielmehr sollen Projektteams lernen, sich zwischen den Polaritäten und

Gegensätzen zu bewegen, wie dies in Tab. 4.10 dargestellt ist.

Es gibt Projektsituationen, in welchen Kreativität und Vertrauen absolut im Mittelpunkt

stehen müssen. Später können im selben Projekt Disziplin und Kontrolle im Vordergrund

stehen. Einmal steht die Wertschöpfung im Vordergrund, ein anderes Mal die Wissens-

schöpfung. Mal werden die Entscheide auf empirischen Bewertungen abgestützt und in

einer anderen Situation sollen eigenständige Schlussfolgerungen gezogen werden. Auch

das Wertequadrat in Abschn. 4.4.11.8 liefert gute Ansätze, wie mit Polaritäten umgegan-

gen werden kann.

398

Team

Tab. 4.10 Umgang mit Polaritäten

Beständigkeit

, Innovation

Disziplin

, Kreativität

Kontrolle

, Vertrauen

Arbeiten im System

, Arbeiten am System

Wissensschöpfung

, Wertschöpfung

Eigenständige Schlussfolgerungen

, Empirische Bewertung

Schnelles Handeln

, Gründliches Analysieren

Mechanistisches Weltbild

, Systemisches Weltbild

Reﬂektierte persönliche Wahrnehmung

In der multikulturellen Zusammenarbeit werden immer Unterschiede in den individuellen

Erwartungshaltungen offenbar. Damit ist von den Betroffenen ein hoher Grad an Selbstre-

ﬂexionsfähigkeit gefordert. Die Projektbeteiligten müssen sich immer wieder neu bewusst

machen, dass die persönliche Wahrnehmung selektiv ist und auf einer individuellen Be-

wertung beruht. Es gilt aber auch, sich der Außenwirkung des persönlichen Handelns

bewusst zu sein (Abschn. 3.10.2). Wer sensibilisiert ist auf seine Außenwirkung, kann

Schritt für Schritt lernen, sein Verhalten möglichst ﬂexibel an die aktuelle Situation anzu-

passen.

Kulturelles Wissen

Der Projektleiter braucht ein Grundverständnis über die Kultur, mit der er konfrontiert ist

oder sein wird. Es geht darum, sich der erwarteten Gesten sowie der Bedeutung von Ritua-

len und Zeremonien bewusst zu sein, Tabus vorzubeugen oder auch religiöse Rahmenbe-

dingungen zu kennen. Dies braucht Neugier und auch die Offenheit, sich auf Unbekanntes

einzulassen.

Sprach- und Kommunikationskompetenz

Englisch hat sich in den meisten multikulturellen Projektteams als die Arbeitssprache eta-

bliert. Oft ist dies aber nur für wenige die Muttersprache, manchmal auch für niemanden.

Wenn sich einzelne oder mehrere Teammitglieder nicht in ihrer Muttersprache ausdrücken

können, braucht es vor allem ein hohes Maß an gegenseitiger Toleranz in der verbalen

Kommunikation. Wer da jedes Wort auf die Goldwaage legt, wird es schwierig haben.

Vielmehr geht es darum, dass sich alle Personen bewusst sind über die Fehleranfälligkeit

des Kommunikationsprozesses, vom Codieren bis zum Decodieren. Das beste Hilfsmittel,

um Irritationen und Missverständnisse zu vermeiden, ist im direkten Gespräch das aktive

Zuhören und natürlich regelmäßiges Feedback.

Führungskompetenz

Im klassischen Projektmanagement braucht es ein Bewusstsein dafür, welche Führungssti-

le in einer bestimmten Kultur überhaupt anwendbar sind. Im agilen Ansatz ist es wiederum

4.1

Zusammenarbeit und Führung

399

wesentlich, darauf sensibilisiert zu sein, wie unterschiedliche Personen an die Selbststeue-

rung herangeführt werden können. Diese Kompetenzen helfen über viele Problemsituatio-

nen in einem multikulturellen Projektteam hinweg.

Beispiel

Wie kann ich überzeugen?

Wie sind Sitzungen zu planen in Bezug auf Erwartungen, Vorbereitung, Agenda,

Leitung, Konsensﬁndung, Pünktlichkeit oder Sprache?

Wer ist dabei und wie steht es mit Aspekten wie Arbeitsethik, Qualiﬁkation und

Networking im anderen Kulturkreis?

Verhandlungsführung

Gerade im asiatischen Raum gelten ganz andere Gesetze in Verhandlungsgesprächen. Die

Methoden der Entscheidungsﬁndung sind für Westeuropäer manchmal etwas ungewohnt.

Allzu direktes Vorgehen kann rasch zu einem Gesichtsverlust führen. Die Projektverant-

wortlichen sind auf genaue Kenntnisse angewiesen, welche Verhandlungsmethoden wann

zur Anwendung kommen können, welcher Einstieg bzw. Abschluss Erfolg versprechend

ist und wer Sitzungen grundsätzlich leiten soll. Mehr dazu unter Abschn. 4.3.

Beispiel

Der westliche Kommunikationsstil ist eher charakterisiert durch Direktheit, „auf den

Punkt bringen“, einen klaren Standpunkt einnehmen, vorwiegend verbal. Der asiatische

Kommunikationsstil ist eher subtil, zirkulär, den Kontext ausleuchtend, vorwiegend

nonverbal. Wir Westler haben hier meistens noch unsere Vorurteile und interpretie-

ren: Wir sind direkt, offen, ehrlich, die andern reden um den Brei herum. Durch die

positive Interpretation sind die Asiaten aber im Trend: Ihr Kommunikationsstil wird

heute dem modernen Management empfohlen. Diese Unterschiedlichkeit muss in ei-

nem Projektteam transparent gemacht werden. Wenn das gelingt, kann ein derartiges

Team komplexere Probleme bearbeiten als ein Team, das nur einen Kulturkreis reprä-

sentiert.

In multikulturellen Projektteams ist es daher wichtiger, dass sie nicht nur virtuell

zusammenarbeiten. Die volle Nutzung dieser Ressourcen kann nur durch gelegentliche

„Face-to-face“-Sequenzen realisiert werden. Besonders beim Projektstart ist eine „physi-

sche“ Begegnung fast unabdingbar.

4.1.14.5

Mit virtuellen Teams effektiv kommunizieren

Virtuelle Teams bestehen aus Personen, welche über die ganze Welt verteilt sind. Sie be-

ﬁnden sich in verschiedenen Zeitzonen, sprechen unterschiedliche Sprachen und haben

unterschiedliche kulturelle Prägungen. Die Kommunikation zwischen den Projektmitglie-

dern ist eine Herausforderung und ﬁndet häuﬁg asynchron und mit digitalen Kommunika-

tionstechnologien statt.

400

Team

Damit die Kommunikation gelingt, empﬁehlt es sich, dass sich die Projektmitglieder

sporadisch persönlich treffen und austauschen. Dieser persönliche Austausch hilft, Blo-

ckaden und Hemmnisse abzubauen und erlaubt Nähe zwischen den Projektmitgliedern

(Abschn. 1.5.2). Dies wird die weitere Kommunikation effektiv fördern. Weiter muss ge-

klärt und festgelegt werden, mit welchen Kommunikationstechnologien (E-Mail, Chats,

Telefon-/Videokonferenzen usw.) und Collaboration-Tools zusammengearbeitet wird.

4.1.14.6

Organisationsaufstellungen

Mit Organisationsaufstellungen können auf eine einfache und efﬁziente Art und Wei-

se verborgene Wirkungsmechanismen, verdeckte Beziehungen, systemische Hinter-

grunddynamiken oder unerkannte Muster sichtbar gemacht werden. Aus Organisa-

tionsaufstellungen können wertvolle Impulse und Erkenntnisse für die Organisations-,

Team- und Personalentwicklung in Projekten gewonnen werden.

Was ist eine Organisationsaufstellung?

„Organisationsaufstellungen bieten einen neuen und andersartigen Ansatz, der sich durch

eine Denkhaltung auszeichnet, die ihren Fokus auf Lösungen legt. Außerdem werden

Systemzusammenhänge berücksichtigt sowie Geschäfts- und Arbeitsbeziehungen mitein-

bezogen. Auch die Art und Weise, wie man zu Ergebnissen kommt, geht neue Wege. Mit

räumlichen und visuellen Eindrücken sowie sprachlichen und körperlichen Ausdrucksfor-

men entsteht ein komplexeres Bild. Durch Organisationsaufstellungen werden komplexe

Zusammenhänge sichtbar und verständlich gemacht und erklärt. Dies hilft, Beziehungen

der Menschen in Organisationen zu verbessern und macht es leichter, die Haltungen der

einzelnen Personen zu verändern. Eine wertvolle Unterstützung sind Organisationsaufstel-

lungen auch dann, wenn es um die bessere Zusammenarbeit von Menschen verschiedener

Kulturen geht. So können durch diese Form der Aufstellung beispielsweise die Konﬂikte

zwischen Organisationseinheiten oder Projektteams in verschiedenen Ländern nachge-

stellt und somit die wirkenden Verhaltensdynamiken auf einer tieferen Bewusstseinsebene

verstanden werden. Das sogenannte ,Bauchgefühl‘, die intuitive Wahrnehmung bzw. das

,innere Wissen‘, lässt sich durch die Aufstellung überprüfen, indem es im Außen in sicht-

bare Bilder übersetzt wird. Auf dieser Basis können Führungskräfte und Projektleiter mehr

Sicherheit für ihre Entscheidungen gewinnen und die ihnen zugrunde liegenden Haltungen

effektiv überprüfen“ (Klein und Limberg-Strohmaier 2012, S. 40).

Was passiert in einer Organisationsaufstellung?

„In Systemaufstellungen werden mit Hilfe von Stellvertretern bzw. Repräsentanten – eine

Art Rollenspiel – Aspekte einer komplexen Situation im Raum dargestellt. Dabei kommt

es in doppelter Hinsicht zu einer Klärung: Einerseits wird die Situation visualisiert – in

Szene gesetzt – und andererseits lassen sich sukzessive kreative Lösungsoptionen heraus-

arbeiten“ (Rosselet und Senoner 2010, S. 20).

Die Repräsentanten dienen als Resonanzkörper für das implizite Wissen. Das implizi-

te Wissen ist zwar vorhanden, aber es ist einer bewussten Reﬂexion nicht ohne Weiteres

4.1

Zusammenarbeit und Führung

401

zugänglich. Die ausgewählten Repräsentanten haben von Vorteil keine Beziehung zur auf-

stellenden Person und zum Thema der Systemaufstellung. Dadurch wird sichergestellt,

dass diese Personen unvoreingenommen an die Aufstellung herangehen. Eine Aufstellung

wird meist mit einer Personengruppe in der Größe von fünf bis 15 Personen unterstützt.

Sollen die verborgenen Wirkungsmechanismen in einem Team für das ganze Team visua-

lisiert werden, so kann auch direkt mit den betroffenen Personen des Teams gearbeitet

werden.

Ablauf einer Organisationsaufstellung

Ein Product Owner, Scrum Master, Projektleiter oder ein anderer Entscheidungsträger hat

eine Fragestellung, ein Ziel oder ein Thema, welches er vertieft anschauen und zu dem er

neue Erkenntnisse für mögliche Handlungsfelder gewinnen möchte. Zum Beispiel möchte

ein Projektleiter die Dynamik seines Projektteams analysieren und die Gründe für einen

unterschwellig laufenden Konﬂikt herausﬁnden.

Der Aufstellungsleiter wird zusammen mit dem Projektleiter in einem ersten Schritt

das Ziel der Aufstellung und die daraus abgeleiteten Fragestellungen besprechen. Ge-

meinsam mit dem Projektleiter wird er weiter die Repräsentanten für die Aufstellung

bestimmen. Der Projektleiter wählt intuitiv die Repräsentanten aus einer Personengruppe

aus und stellt diese nach seinem Bauchgefühl im Raum auf. Dadurch werden die Bezie-

hungsstrukturen des Projektteams visualisiert. Das Anfangsbild spiegelt normalerweise

die aktuelle Situation des aufgestellten Projektteams wider. Daraus können bereits die

ersten Rückschlüsse gezogen werden. Der Aufstellungsleiter wird nun gezielt Interventio-

nen herbeiführen, z. B. Repräsentanten umstellen oder weitere Elemente (Repräsentanten)

in die Aufstellung holen. Bei jeder Intervention beobachten Aufstellungsleiter, Repräsen-

tanten und Projektleiter, wie sich die Intervention auf das aufgestellte System auswirkt

und welche Veränderungen sichtbar werden. Aus diesen Erkenntnissen lassen sich Ent-

wicklungspotenziale und Lösungswege identiﬁzieren. Dadurch können verborgene oder

verdeckte Themen visualisiert werden, welche dem analytischen Verstand alleine verbor-

gen bleiben.

Eine Organisationsaufstellung dauert eine bis eineinhalb Stunden. Das Verfahren der

Systemaufstellung ist effektiv, schnell und unkonventionell.

Für einen Product Owner, einen Scrum Master oder einen Projektleiter empﬁehlt es

sich, für eine Organisationsaufstellung einen außenstehenden Aufstellungsleiter hinzuzu-

ziehen, welcher nicht Teil des zu betrachtenden Systems ist.

Anwendungsmöglichkeiten von Organisationsaufstellungen im Projektumfeld

Für Organisationsaufstellungen gibt es im Projektumfeld eine Vielzahl von Anwendungs-

möglichkeiten(in Anlehnung an Weber: Basics des Aufstellens von Organisationen und

Arbeitsbeziehungen, Grundlagen und Vorgehensweisen in Weber und Rosselet (2016),

Organisationsaufstellungen – Grundlagen, Settings, Anwendungsfelder):

402

Team

Strukturelle „Klemmen“ sichtbar werden lassen und analysieren

– Strukturelle Widersprüche in der Projekt- oder Stammesorganisation

– Unklare Organisationsstrukturen, z. B. unpassende Zuordnung von Kompetenz- und

Aufgabenbereichen

– Unklare Rollenzuordnungen und Rollenbeschreibungen

– Sichtbarmachen verdeckter Interessen und Ansprüche von Stakeholdern

– Bei mangelhafter Kommunikation und Koordination

Maßnahmen vorbereiten und begleiten (Analyse und Probehandeln)

– Zielﬁndungsprozesse, Ausrichtung des Projektes

– Antizipieren von Auswirkungen möglicher Maßnahmen in der Entwicklung von Or-

ganisationen, Teams, Projektgruppen usw.

– Vorbereitung von Verhandlungen

Personalentscheidungen und Personalentwicklung vorbereiten

– Personalauswahl

– Besetzung von Schlüsselpositionen im Projekt

– Im Rahmen von Personalentwicklungsmaßnahmen

– Wie kommt jemand in der Projektorganisation in seine Kraft

Leitungsqualität und Führungsverhalten überprüfen

– Adäquate Besetzung und adäquates Ausfüllen von Leitungsfunktionen im Projekt

Sinnstiftende Hypothesen erzeugen und Lösungen in konﬂiktreichen Beziehungssitua-

tionen fördern

– Ursachen und Lösungswege bei Konﬂikten

– Mangelnde Achtung und Würdigung

– Koalitionsbildung und Triangulierung

– Kontextvermischung zwischen privatem und geschäftlichem Bereich

– Angemaßtes Verhalten und Verweigerung

– Nicht eingenommene Plätze, nicht in Anspruch genommene Projektrollen, innere

Kündigung, Tendenz, sich zurückzuziehen

– Ausklammerung, Mobbingdynamik

Projektkultur und Arbeitsklima

– Das Energieniveau des Projektes

– (De-)Motivationen, Boykottierungen

– Gemeinschaftsgefühl, Zusammenhalt

– Hintergründe und Zusammenhänge für anhaltende Mitarbeiterﬂuktuation oder ho-

hen Krankenstand

Informationen über fehlenden Rückhalt und mangelnde Unterstützung gewinnen

Projektorganisationen (Mitarbeiter) auf Aufgaben, Ziele und Kunden ausrichten

Bei Entscheidungsﬁndungen unterstützen

Diese und weitere Anwendungsmöglichkeiten gelten natürlich auch außerhalb der Pro-

jektarbeit in allen Fragen der Organisations- und Personalentwicklung.

4.2

Dynamik in Teams

403

4.2

Dynamik in Teams

Ob wir agil oder klassisch unterwegs sind, nach B. Tuckman durchläuft jedes Team in

einer jeweils speziﬁschen Form bestimmte Phasen eines Teamentwicklungsprozesses. Für

die fünf in Abb. 4.13 dargestellten Phasen haben sich die englischen Begriffe etabliert:

Forming, Storming, Norming, Performing und Adjourning. Jede dieser Phasen beinhaltet

speziﬁsche Herausforderungen, Chancen und auch Gefahren, die nachfolgend beschrieben

sind (Gellert und Nowak 2007, S. 192 ff.).

4.2.1

Forming: Orientierung

In Teams, welche neu zusammengestellt werden – wie bei einem Projekt Kick-off –,

herrscht zu Beginn eine mehr oder weniger starke Unsicherheit. Die Mitglieder der Grup-

pe fragen sich, was da genau auf sie zukommt, welches die persönliche Rolle sein wird,

welche Spielregeln eingehalten werden müssen oder auch wer die anderen Teammitglie-

der sind und wie diese die Aufgaben anpacken werden.

Arbeitsgruppe

Entwickelte Gruppe

Wandel

Spitzenteam

Leistungsfähigkiet

Teamentwicklung

Adjourning

Abschied und

Trennung

Projektreview

Erfolge

Ungleichzeitigkeit

hoch

klein

Forming

Orientierung

Öffnung

Zugang

Sicherheit

Storming

Auseinander-

setzung

Regeln

Standfestigkeit

Aufmerksamkeit

Kommunikation

Norming

Vertrautheit

Raum geben

Grenze bewahren

Festhalten an

Zielen

Performing

Arbeit im System

Beraten

Controlling

Selbstüberschät-

zung erkennen

Konﬂikt

Gefahr der

Umkehr

Gefahr eines

Konﬂikts

Abb. 4.13 Fünf Entwicklungsphasen von Teams nach Tuckman

404

Team

Entsprechend ihren persönlichen Charaktereigenschaften verhalten sich die Teammit-

glieder in dieser Phase ganz unterschiedlich: Die einen sind neugierig und erwartungsvoll,

andere sind eher zurückhaltend oder skeptisch.

Die Forming-Phase ist gekennzeichnet durch höﬂiches, zurückhaltendes und eher di-

stanziertes Verhalten der Mitglieder. Es existiert noch kein Team im eigentlichen Sinne.

Die wichtigsten Aufgaben für die Teamentwicklung in dieser Phase sind:

Öffnung: Die Projektverantwortlichensollen Rahmenbedingungen schaffen

undInterventionen durchführen,welche den einzelnen Gruppenmitgliedern

erlauben, sich kennenzulernen und Vertrauen zueinander zu entwickeln.

Zugang: Zugang finden zum inhaltlichen Projektziel. Je nach Auftrag geht

es darum, die Bereitschaft zu erreichen, sich auf etwas Neues einlassen zu

können.

Sicherheit: Um die Unsicherheit abzubauen, ist so gut wie möglich die Ar-

beitsfähigkeit herzustellen. Dazu gehört es, die Projektorganisation mit den

jeweiligen Rollen (agil oder klassisch) zu klären, Berichtswege und Informati-

onsfluss festzulegen oder auch die ganze Dokumentenverwaltung zu erläu-

tern. Das hilft den Einzelnen, sich in dieser ersten Phase zurechtzufinden.

Die sorgfältige Vorbereitung und Durchführung des Kick-offs leistet einen wertvol-

len Beitrag, gut mit den Herausforderungen in dieser ersten Phase der Teamentwicklung

umzugehen.

4.2.2

Storming: Auseinandersetzung

Nachdem sich ein Team durch das Forming gebildet hat, beginnt die Arbeit an den in-

haltlichen Zielen und Aufgaben. Die Arbeit im System steht im Vordergrund, das System

selber mit der Beziehungs- und Organisationsebene ist meist noch schwach ausgeprägt.

Die Teammitglieder legen nun die ursprüngliche Zurückhaltung ab und zeigen sich of-

fener in ihren persönlichen Charakterzügen. Nachdem im Forming die Teamstruktur auf

der formellen Ebene über das Organigramm oder die Rollenzuschreibungen geregelt wur-

de, muss sich das Team nun auch auf der informellen Ebene ﬁnden. Diese Phase kann

recht unproblematisch sein, wenn sich die Teammitglieder schon kennen und die Team-

entwicklung schon in anderen Projekten durchlaufen haben. Sind aber Friktionen und

Animositäten aus einer vorhergehenden Zusammenarbeit noch immer nicht gelöst, fordern

(neue) Teammitglieder die formelle oder informelle Teamorganisation heraus. Oder eine

übergeordnete Stelle delegiert einen Konﬂikt in das Projekt (Abschn. 4.4.2). Dann kommt

es in dieser Phase zu Auseinandersetzungen und Konﬂikten. In der Storming-Phase ist die

Gruppe geprägt von einer gespannten Erwartungshaltung und der Hoffnung auf eine gute

Zusammenarbeit. Gleichzeitig ist dieses junge Team noch sehr störungsanfällig.

4.2

Dynamik in Teams

405

Die wichtigsten Aufgaben im agilen und klassischen Projektmanagement sind:

Regeln: Die am Kick-off festgelegten Regeln werden nun vom Team auf ihre

Stabilität ausgetestet. Die Projektverantwortlichen müssen ein wachsames

Auge dafür haben, welche Regeln der Zusammenarbeit wirkungsvoll sind

und wo auch noch Verbesserungen wahrgenommen werden können.

Standfestigkeit:Die Teammitglieder prüfen in dieser Phase die unterschied-

lichen Rollen und Gremien (agil oder klassisch) auf ihr Durchsetzungsver-

mögen und ihre (Sach-)Kompetenz. Sie werden vermehrt mit Fragen und

manchmal auch mit Angriffen konfrontiert. Hinter diesem Verhalten steckt

auch das Grundbedürfnis nach sozialer Anerkennung in der Gruppe. Eine gu-

te Gelassenheit und Standfestigkeit werden den Verantwortlichen in dieser

Phase helfen, die persönliche Rolle in der Gruppe zu festigen.

Aufmerksamkeit: In dieser Phase spielt die Gruppendynamik auf mehreren

Ebenen. Nicht alles muss thematisiert und bearbeitet werden. Aber überall

da, wo die Arbeitsfähigkeit des Teams beeinträchtigt wird, müssen Scrum

Master oder Projektleiter intervenieren. Hilfestellung bietet dafür das Kon-

fliktmanagement oder der Umgang mit Widerstand.

Kommunikation: Um diese Phase gut zu meistern, braucht es eine gut ent-

wickelte Kommunikations- und Feedbackkultur. Nur wenn Kommunikation

und Feedback auf ihre klärende Wirkung angelegt sind und nicht werten, ist

es den Gruppenmitgliedern möglich, sich angstfrei untereinander auszutau-

schen. Das agile Projektmanagement kennt hierfür eine wertvolle Plattform:

das Daily Standup Meeting. Dadurch, dass die Besprechung täglich stattfin-

det,wirdeinehoheTransparenzgeschaffen.Dieshilft,Spannungenzwischen

Personen oder Teams zu bearbeiten, bevor sie aus dem Ruder laufen.

In der Storming-Phase ist die inhaltliche Arbeit oft mühsam und langsam. Diese Arbeit

im System soll hier aber gar nicht im Vordergrund stehen. Viel wichtiger ist die Arbeit

am System. Jedes Verhalten der beteiligten Personen kann differenziert beleuchtet werden

in Bezug auf Symptom und Ursache. In der Auseinandersetzung mit den wesentlichen

Ursachen liegt die große Chance, die Arbeit am System derart weiterzuentwickeln, dass

das Fundament für ein Hochleistungsteam gebildet werden kann. Gerade dadurch, dass

sich Scrum Master und Projektleiter in dieser Phase auf die Arbeit am System fokussieren,

schaffen sie die Ausgangslage für die nächste Gruppenphase.

4.2.3

Norming: Vertrautheit

Durch die Auseinandersetzung mit den unterschiedlichen Friktionspunkten, Konﬂikten

oder Widerständen können die Ängste der Betroffenen abgebaut werden und die Rollen

weiter geklärt werden. Das schafft Sicherheit. Schwierigkeiten und persönliche Bedürf-

nisse offen anzusprechen steigert den inneren Zusammenhalt in der Gruppe. Nun kann

406

Team

Tab. 4.11 Fördernde und hemmende Einﬂussfaktoren für die Kohäsion

Günstige Gruppengröße (5–8 Personen),

Zu kleine oder zu große Gruppe,

Häuﬁge Interaktionen,

Einsame Einzelkämpferarbeit,

Kollektive Leistungsbewertung und

Individuelle Leistungsbewertung und

Offene, ehrliche Kommunikation

Intransparente Kommunikationskultur

Fördern die Kohäsion

Hemmen die Kohäsion

eine Gruppenidentität entstehen. Die Einzelnen haben ihre Position innerhalb der Gruppe

gefunden.

Gerade dank der gemeinsam bestandenen Herausforderung des Stormings wächst das

gegenseitige Vertrauen (Abschn. 3.3.7). Dadurch kann Kohäsion in der Gruppe entstehen.

Kohäsion steht für das Gemeinschaftsgefühl und die Solidarität, die in einem Team

besteht. Auf die Stabilität einer Gruppe hat Kohäsion einen wesentlichen Einﬂuss. Das

Team ist für seine Mitglieder attraktiv geworden. Neue Gruppennormen fördern auch ein

offeneres und persönlicheres Verhalten.

In Tab. 4.11 sind kohäsionsfördernde und -hemmende Maßnahmen und Rahmenbedin-

gungen dargestellt.

Das Ganze hat aber auch eine Schattenseite: Je höher die Kohäsion in einer Gruppe,

desto schwieriger ist es für neue Teammitglieder, in das bestehende Gruppengefüge hin-

einzukommen.

Als Konsequenz der neu gewonnenen Vertrautheit rückt auch der Arbeitsinhalt mehr in

den Hintergrund. Die Beziehungsebene steht in dieser Phase im Vordergrund.

Die wichtigsten Aufgaben für die Teamentwicklung in dieser Phase sind:

Raum geben: Zu viel inhaltlichen Druck aufzubauen ist in dieser Phase nicht

sinnvoll. Die Gruppe soll den Stress der Auseinandersetzung abbauen kön-

nen und das soziale Gefüge festigen. Die Empfehlung ist sogar, in dieser

Phase weitere, vertrauensstärkende Maßnahmen anzubieten.

Grenzewahren:In dieser Phase ist esfür die Projektverantwortlichen verfüh-

rerisch, sich in die Vertrautheit der Gruppe einzuschmeicheln. Dieser Verlo-

ckung ist zu widerstehen: Die Grenze zwischen dem Team und den weiteren

Rollenträgern im Projekt ist zu wahren.

An den Zielen festhalten: Die Arbeit ist zwar nicht mehr mühsam wie im

Storming, aber die Produktivität ist auch nicht sehr hoch. Die Gruppe ist auf

die Zielsetzung und die Performing-Phase auszurichten.

Um die Teamentwicklung zu unterstützen, eignen sich die Modelle zur Selbsterkennt-

nis Abschn. 3.10.2 oder auch Organisationsaufstellungen Abschn. 4.1.14.6. Die Personen

haben nun das Vertrauen, miteinander über die eigenen Stärken und Schwächen zu reden.

4.2

Dynamik in Teams

407

4.2.4

Performing: Arbeit im System

Ein erfolgreicher Durchlauf der vorhergehenden Phasen steigert die Kooperationsfähig-

keit und die Kooperationsbereitschaft. Nun steht die konstruktive Zusammenarbeit – die

Arbeit im System – im Vordergrund. Die Gruppenmitglieder sind motiviert und zeigen Ei-

geninitiative. Die Performanz zeigt sich nicht nur in guter inhaltlicher Arbeit, sondern vor

allem auch in der Eigeninitiative der Gruppenmitglieder für Zusammenarbeit, Organisati-

on und gegenseitige Abstimmung. Es braucht jetzt nur noch minimale formale Führung.

In agilen Projektteams wird der Scrum Master jetzt nur noch wenig gebraucht. In dieser

Phase werden die

Gruppenregeln und -normen offen untereinander kommuniziert und von allen Personen

mitgetragen;

Einzelbedürfnisse und das Gruppeninteresse gut miteinander ausbalanciert und

die wesentlichen Arbeitsabläufe effektiv abgewickelt, frei von Koalitionen und Kon-

kurrenz.

Die Gruppe hat nun einen hohen Reifegrad erreicht. Die Beziehungsarbeit steht nicht

mehr im Vordergrund, die Energie wird nicht mehr durch Rivalitäten und Konﬂikte absor-

biert. Das gemeinsame Ziel steht im Vordergrund.

Die wichtigsten Aufgaben für die Teamentwicklung in dieser Phase sind:

Beraten: Sicherstellen,dass die Prozesse eingehalten werden. Bei Bedarf be-

ratend zur Seite stehen.

Controlling: Im klassischen Projektmanagement ist zu prüfen, dass die Ar-

beitspakete und Zwischenziele wirklich in der notwendigen Qualität abge-

schlossen sind(z. B.90 %Syndrom Abschn.2.5.6.5).Zudem ist sicherzustellen,

dass auch die weniger populären Arbeiten wie die Dokumentation oder das

Konfigurationsmanagement dem Projektverlauf entsprechend nachgeführt

werden. Im agilen Projektmanagement prüft der Product Owner die qualita-

tiven Ziele im Sprint Review. Dazu bietet sich das Sprint Burndown Chart als

wertvolle Quelle an, die effektive Leistung des Teams im Blick zu behalten.

Selbstüberschätzung erkennen: Es kann so weit kommen, dass ein Team

sein Selbstbild völlig überschätzt. Die Projektverantwortlichen müssen Aus-

sagen wie „wir sinddie Besten“,verbunden mit der Abwertung anderer Grup-

pen, stoppen.

Bildlich gesprochen, können Scrum Master und Projektleiter in dieser Phase die Rolle

des Schiedsrichters in einem Fußballspiel einnehmen. Sie beobachten das Geschehen aus

einer gewissen Distanz und intervenieren nur dann, wenn die Regeln verletzt werden.

Ansonsten lassen sie das Spiel laufen und bereiten sich auf die nächste Phase vor.

408

Team

4.2.5

Adjourning: Abschied und Trennung

Jedes Projekt kommt zu einem Ende. Damit wird auch das Projektteam wieder aufgelöst.

Im klassischen Projektmanagement wird diese Phase mit der Projektschlussbeurteilung

leider oft vernachlässigt, weil schon die nächsten dringenden Projekte und Aufgaben war-

ten.

Dabei birgt gerade diese letzte Phase ein großes Potenzial für die persönliche und kol-

lektive Weiterentwicklung: Hier können der Gruppenprozess wie auch die persönliche

Rolle reﬂektiert werden. Das ist die Grundlage der lernenden Organisation: Die Erfah-

rungen sind immer wieder neu zu reﬂektieren. Zwischen Symptom und Ursache ist zu

unterscheiden. Abschließend sind neue Handlungsmuster und Maßnahmen abzuleiten, um

die Effektivität der Projektarbeit weiterzubringen.

Durch den Prozess der Trennung soll auch vermieden werden, dass einzelne Personen

mit Altlasten oder Ambivalenzen aus der Zusammenarbeit ausscheiden, womit sie künfti-

ge Projekte belasten.

Die wichtigsten Aufgaben für die Teamentwicklung in dieser Phase sind:

Projektabschluss oder Retrospektive: Diese Plattformen benötigen klare

Strukturen, die sicherstellen, dass der Inhalt und die Verbesserung der zu-

künftigen Projektabwicklungen im Mittelpunkt stehen und niemand persön-

lich angegriffen oder abgewertet wird. Eine kompetente Moderation dieses

Anlasses ist wichtig. Im agilen Projektmanagement ist hierfür der Scrum Mas-

ter prädestiniert. Im klassischen Ansatz liegt die Verantwortung grundsätz-

lich beim Projektleiter. Für den Projektreview empfiehlt sich jedoch oft eine

neutrale, externe Moderation: Der Projektleiter kann dadurch während des

Projektreviews vollumfänglich die Rolle eines Mitgliedes der Projektorgani-

sation einnehmen. Somit ist er nicht in einer Doppelrolle mit der Verantwor-

tung für die Gestaltung des Prozesses.

Erfolge: Soziale Anerkennung ist ein wesentliches Grundbedürfnis des Men-

schen. Die Erfolge sollen gefeiert werden, das Team soll die Würdigung er-

halten, die es sich verdient hat. Ein Team-Event hat hierfür immer eine sehr

gute Wirkung, auch auf das zukünftige Commitment der Mitarbeiter. Zusätz-

lich kann im Sinne einesProjektmarketingsauch ein Artikel in einem internen

Organ publiziert werden.

Ungleichzeitigkeit: Vor allem im klassischen Projektmanagement ist die

letzte Phase dadurch gekennzeichnet, dass immer wieder Personen abgezo-

gen werden.In dieser Phase die Fäden zusammenzuhalten undauch dafür zu

sorgen, dass alle Personen an den wesentlichen Anlässen dabei sein können,

liegt bei den Projektverantwortlichen.

4.3

Verhandlungsführung

409

4.2.6

Dynamiken und Wechselwirkungen

Die Phasen der Teamentwicklung werden nicht immer der Reihe nach durchlaufen. Auch

die Intensität, in welcher sich eine Phase manifestiert, kann ganz unterschiedlich sein. Es

gibt auch keine Garantie dafür, dass ein Team, welches im Performing angekommen ist,

bis zu seiner Auﬂösung in dieser Leistungsfähigkeit bleibt. Scrum Master wie Projekt-

leiter sollen sensibilisiert sein auf alle Arten von Störungen, die das Teamgefüge wieder

neu herausfordern: Dies betrifft vor allem Veränderungen in der Zusammensetzung der

Projektorganisation. Wenn neue Personen in die Gruppe eintreten oder andere sie verlas-

sen, können ganz neue Dynamiken entstehen. Ein Team im Performing kann damit – wie

in Abb. 4.13 dargestellt – wieder in die Storming-Phase zurückfallen und muss auch das

Norming wieder durchlaufen. Dasselbe kann auch auftreten, wenn der interne oder externe

Auftraggeber wesentliche Änderungen an einem der Parameter des magischen Dreiecks

vornimmt, oder wenn das Projektteam zu wenig gut geschützt werden kann vor Zugrif-

fen aus der Stammorganisation. Das ist oft der Fall, wenn einzelne Teammitglieder mit

operativ höher priorisierten Aufgaben beauftragt werden. Das reduziert dann ihre Leis-

tungsfähigkeit für das Projekt.

Die Herausforderung des Teamentwicklungsprozesses ist, dass das Performing

nur über Storming und Norming erreicht werden kann. Der Konflikt im Stor-

ming bildet das Fundament für das spätere Performing. Teams, denen die

Kompetenzen zum Konfliktmanagement fehlen, werden in dieser Konfliktwalze

stecken bleiben. Die Arbeit ist von Anfang bis Ende mühsam, anstrengend und

unbefriedigend.

4.3

Verhandlungsführung

4.3.1

Verhandlungen im Projektmanagement

Die Anlage der Projektarbeit mit dem Innovationsauftrag, der Zielorientierung sowie der

interdisziplinären Zusammenarbeit auf beschränkte Zeit hat eine natürliche Konsequenz:

Permanent müssen unterschiedliche Interessen, Anforderungen, Überzeugungen oder Ab-

sichten aufeinander abgestimmt werden. Dies alles im Rahmen des magischen Dreiecks,

welches sich aus den Einﬂussfaktoren „Scope“, „Zeit“ und „Kosten“ zusammensetzt

(Abschn. 2.3.4).

Zu Beginn eines Projektes gehört es zu den wesentlichen Aufgaben des Projektlei-

ters oder Product Owners, einen Projektauftrag zu verhandeln, der „Scope“, „Zeit“ und

„Kosten“ in ein realistisches Verhältnis zueinander setzt. Auch während der Projektab-

wicklung muss immer wieder verhandelt werden, sei das im Change Request Management

(Abschn. 2.5.8), im Problemlösungsprozess (Abschn. 2.3.15) oder in der Rollenklärung

(Abschn. 4.1.9). Damit ist die Verhandlungsführung eine wichtige Kompetenz in der Pro-

410

Team

jektarbeit: Wer ein Projekt startet mit illusorischem Scope, Zeitplan oder Budget, steigert

das Projektrisiko und stellt auch das Team vor unrealistische Herausforderungen. Wer

keine Projektrollen und -verantwortlichkeiten verhandeln kann, kann nur die Erwartungen

anderer erfüllen und damit seinem persönlichen Selbstmanagement (Abschn. 3.8) nicht

gerecht werden.

Verhandlungen leben – wie auch das Projektmanagement – von der Vielseitigkeit

(Abschn. 1.7.1). Wie in einem Schachspiel werden verschiedene Szenarien vorbereitet,

um in der Situation selber schnell und ﬂexibel reagieren zu können. Das bedeutet, dass

die Vorbereitung ein wesentlicher Erfolgsfaktor für wichtige Verhandlungen ist.

4.3.2

Was ist eine Verhandlung?

I Eine Situation wird als Verhandlung bezeichnet, wenn zwei oder mehrere Parteien,

die unterschiedliche Ansichten vertreten und/oder individuelle Ziele verfolgen,

die mit Handlungs- und Entscheidungskompetenz ausgestattet sind,

die ein Interesse an einer Lösung haben und/oder

unter dem Druck stehen, eine Einigung bzw. ein Ergebnis zu erzielen,

im Gespräch versuchen, bezüglich einer Frage oder eines Themenkomplexes eine Eini-

gung zu erzielen. André Baer

Anlass für eine Verhandlung ist eine Differenz bezüglich Ansichten oder Zielen. Zu-

dem muss ein Interesse an einer gemeinsamen Lösung bestehen oder sogar ein Eini-

gungszwang. Wichtigste Voraussetzung für eine Verhandlung sind die Handlungs- und

die Entscheidungsfreiheit der beteiligten Parteien. Diese sind in der Projektarbeit abhän-

gig von der Anbindung des Projektes an die Stammorganisation (Abschn. 2.3.9.8) sowie

von der Rollenklärung mit den A-K-V: Ist das Projekt z. B. über Koordination in die Linie

integriert, ist der Projektverantwortliche lediglich ein Projektkoordinator. In dieser Rolle

hat er wenig bis gar keine Entscheidungskompetenzen. Er ist zur Verhandlungsführung

nicht legitimiert.

Verhandlungen weisen Parallelen zu Konﬂikten auf. Deshalb wird beim Thema Kon-

ﬂiktbewältigung (Abschn. 4.4.10.4) auf Elemente aus der Verhandlungsführung eingegan-

gen.

4.3.3

Verhandlungszyklus

Eine Verhandlung ist ein komplexer Prozess. Deshalb ist es wichtig, dass die Vorgehens-

weise in Verhandlungen dieser Komplexität gerecht wird. Der nachfolgend beschriebene

4.3

Verhandlungsführung

411

Situation

Ziele

Informationen

Strategie

Taktiken

Analyse

Massnahmen

Kontaktphase

Kernphase

Vereinbarungs-

phase

Abb. 4.14 Verhandlungszyklus nach André Baer

Verhandlungszyklus (Abb. 4.14) bildet eine Leitlinie, die sich in der Praxis vielfach be-

währt hat. Der Prozess besteht aus den drei Hauptphasen „Vorbereitung“, „Verhandlung“

und „Auswertung“.

4.3.3.1

Vorbereitung

Die Vorbereitung ist für die Verhandlungsführung zentral. Für komplexe Verhandlungen

kann diese Wochen oder auch Monate dauern. Die Vorbereitungsphase besteht aus fünf

Schritten:

Situation: Probleme und Bedürfnisse

Bevor jemand eine Verhandlungstechnik und -strategie wählt, analysiere er in einem ersten

Schritt die Situation. Dabei stehen die gegenwartsbezogenen Probleme und Bedürfnisse

im Mittelpunkt, oder – in der Sprache der Projektmanagementmethodik – die Zielsetzun-

gen (Abschn. 2.3.2). Folgende Punkte oder Fragen sind zu klären:

Worum geht es? Wo besteht eine Differenz, was ist der Verhandlungsgegenstand?

Besteht überhaupt ein Verhandlungsspielraum? Oder muss einfach eine schlechte

Nachricht überbracht werden?

412

Team

Welche Personen sind involviert? Welche Handlungsfreiheit haben sie?

Bei Kundenprojekten: Welche Aspekte oder Rahmenbedingungen sind durch den Ver-

trag vorgegeben?

In konﬂiktbeladenen Situationen ist zusätzlich zu klären:

Worum geht es den Parteien wirklich?

Inwiefern kann eine Unterscheidung gemacht werden zwischen Symptom und Ursa-

che?

Ziele

Die Ziele werden aus der Gegenwartsperspektive heraus entwickelt. Sie öffnen die Zu-

kunftsperspektive. Oft ist es ein Leichtes, Probleme zu benennen. Lösungsansätze positiv

zu formulieren ist jedoch beträchtlich schwieriger. Beim Formulieren von Zielen muss

sich die Verhandlungspartei auch im Klaren darüber werden, welche Priorität welches

Ziel für sie einnimmt. In diesem Schritt geht es zudem nicht nur um die eigenen Prio-

ritäten und Ziele. Auch die Ziele und Prioritäten des Verhandlungspartners müssen hier

einbezogen werden.

Die Zielpyramide Abb. 4.15 erlaubt es, die eigenen Ziele und deren Prioritäten zu

konkretisieren und Annahmen darüber zu treffen, wie diese aus der Perspektive des Ver-

handlungspartners aussieht.

Die persönlichen Ziele sind so konkret wie möglich zu beschreiben. Folgende Punkte

oder Fragen sollen dazu geklärt werden:

Was muss ich zwingend erreichen (Must have), wo liegen meine Grenzen? Werden

diese Minimalziele nicht erreicht in der Verhandlung, würde das bedeuten, die Ver-

handlung abzubrechen (Walk-away-Position).

Welche Ziele strebe ich in einem realistischen Szenario an, womit kann ich rechnen

(Want-to-have-Position)?

Welche Ziele sind ebenfalls erstrebenswert (Nice-to-have)?

Welche Alternativen sind möglich? Was wäre ein Plan B?

Wir können nie abschließend wissen, welche Ziele der Verhandlungspartner ver-

folgt. Aber wir können Annahmen treffen resp. Hypothesen bilden (Abschn. 4.4.8.1).

Dazu versetzen wir uns in die Lage des Gegenübers, wechseln die Perspektive. Folgende

Punkte oder Fragen sind zu klären:

Welche Ziele verfolgt mein Gegenüber?

Bei Kundenprojekten: Welchen Einschränkungen oder Bedingungen ist mein Verhand-

lungspartner durch seine Organisation unterworfen?

4.3

Verhandlungsführung

413

Datum:

Verantwortlicher:

Unsere Ziele

1. Beziehung zum Kunden

2. Auftragslage sichern

3. Reputation schützen

4. Kunde nicht verlieren

5. Deckungsbeitrag

sicherstellen

Ziele des Verhandlungspartners

1. Verlässliche Lieferanten

2. Kein Produktionsausfall

wegen Lieferverzug

3. Kostenoptimierung

4. Kein Mehraufwand durch

neue Lieferantenevaluation

Abb. 4.15 Beispiel Zielpyramide für ein Kundenprojekt

Informationen

Basierend auf den konkretisierten Zielen werden sämtliche Informationen gesammelt und

bewertet, die in irgendeiner Art und Weise für die Verhandlung relevant sein können:

Welche Verhandlungsspielräume bestehen?

Wo liegen bei jedem Verhandlungspunkt die möglichen Einigungsbereiche?

Wo liegt die Grenze? Wann müsste eine Verhandlung abgebrochen werden?

Welche rechtlichen Einschränkungen müssen berücksichtigt werden?

Strategien

Die Wahl der Verhandlungsstrategie (Abb. 4.16) orientiert sich an den ähnlichen Krite-

rien wie die Stakeholder-Analyse (Abschn. 2.3.5): Beziehungen, Interessen, Macht und

Forderungen.

Je stärker ausgeprägt die Beziehungen und Interessen sind, desto kooperativer ver-

halten sich die Verhandlungsparteien. Je größer die Forderungen sind und je stärker die

Verhandlungsparteien die ihnen zugänglichen Machtquellen einsetzen, desto fordernder

werden sie auftreten.

414

Team

hoch

tief

kooperativ

unkooperativ

Anpassungs-Strategie

• Eigene Interessen opfern

• Sich unterordnen, um die Beziehung

zu entspannen

Kooperative Strategie

• Die Einigung ist das Ziel

• Fokus auf Schaffung beiderseits

vorteilhafter Optionen

Kompromiss-Strategie

Wechselseitig Konzessionen

machen, vertretbare Einigung ﬁnden

Ausweich-Strategie

• Möchte warten, bis ich meine

Position gestärkt habe

• Vermeiden, dass Beziehung

beschädigt wird

Durchsetzungs-Strategie

• Fokus auf die Differenz, nicht

Gemeinsamkeit

• Fokus auf Verschlechterung fremder

und Verbesserung eigener Alternativen

Beziehung, Interessen

Macht, Forderung

Abb. 4.16 Verhandlungsstrategien nach André Baer

Kooperative Strategie (Integration)

Gelingt es den Verhandlungsparteien, ihre gemeinsamen Interessen in ein Gesamtpaket

zu integrieren resp. eine gemeinsame, nachhaltige Problemlösung in den Mittelpunkt

zu stellen, ermöglicht die kooperative Strategie, optimale Lösungen für alle Parteien zu

ﬁnden. Das Verhandlungsergebnis entsteht mit größtmöglicher Efﬁzienz für beide Seiten.

Ziel ist es, das Pareto-Optimum zu erreichen und nicht das Maximum. Die Vorarbeit dazu

wird in der Zielpyramide geleistet (Abb. 4.15), in der die Art der Verhandlungsziele und

deren Priorisierung einen hohen Deckungsgrad haben.

In der kooperativen Strategie werden die Gemeinsamkeiten hervorgehoben. Es wird

versucht, eine Verhandlungskonstellation zu schaffen, in welcher beide Parteien einen Vor-

teil haben. Diese Strategie lebt von der offenen und ehrlichen Kommunikation. Auf Druck-

mittel wird verzichtet, vielmehr werden Flexibilität im Verhandlungsprozess und Kreati-

vität in der Lösungssuche angewendet. Nach dieser Strategie orientiert sich das Harvard-

Konzept, auf welches weiter unten noch speziﬁsch eingegangen wird (Abschn. 4.3.4).

Durchsetzungs-Strategie (Konfrontation)

In der Durchsetzungs-Strategie ist das Hauptziel, die eigenen Bedürfnisse durchzusetzen,

was zur Folge haben kann, dass sich die Position der Gegenpartei verschlechtert.

4.3

Verhandlungsführung

415

Die Differenzen werden betont. Die Beziehung zum Verhandlungspartner wird nicht

als wichtig gewertet. Darum wird in Kauf genommen, dass diese durch den Prozess leidet,

zerbricht oder sich verhärtet, wenn die Gegenpartei ebenfalls auf Konfrontation setzt.

Anpassungs-Strategie

In der Anpassungsstrategie werden die eigenen Interessen geopfert. Diese Strategie wird

gewählt, wenn die Beziehung zum Verhandlungspartner entspannt werden soll. Gut do-

siert macht diese Strategie situativ Sinn. Es darf aber nicht passieren, dass eine Partei

aufgrund persönlicher Schwächen im Verhandeln permanent ausgenutzt wird.

Kompromiss-Strategie

In der Kompromiss-Strategie ﬁnden sich beide Parteien auf halber Strecke. Beide machen

Konzessionen für eine vertretbare Einigung.

Auch diese Strategie macht situativ Sinn. Auf Dauer macht sie jedoch auch niemanden

glücklich. Deshalb sollte in mittel- und langfristigen Arbeitsbeziehungen darauf geachtet

werden, dass der Kompromiss nicht zum Standard wird.

Ausweich-Strategie

Die Ausweich-Strategie wird gewählt, wenn in der aktuellen Situation eine Auseinander-

setzung vollkommen sinnlos wäre. Wenn das Gegenüber alle Trümpfe in der Hand hat,

sei das inhaltlich oder in Bezug auf die Machtfaktoren, macht es keinen Sinn zu verhan-

deln. Man bleibt inaktiv, um Zeit für weitere Abklärungen zu gewinnen. In dieser Situation

ist es besser, die bestehenden Beziehungen nicht zu riskieren und auf einen günstigeren

Zeitpunkt zu warten.

Beispiel

Wenn der Kunde auf den vertraglich festgelegten Liefertermin besteht, gibt es keinen

Spielraum und damit auch keine Verhandlung im engeren Sinn. Dann kann der Pro-

jektleiter, wenn er den Termin nicht erreichen kann, nicht mit dem Kunden verhandeln.

Dies würde das Kunden-Lieferanten- Verhältnis belasten.

Es wird zu einer verhandelbaren Situation, wenn die involvierten Parteien eine an-

dere Haltung einnehmen, wenn der Projektleiter mit dem Kunden oder seinem Auftrag-

geber über Varianten der Leistungserbringung verhandeln kann. Der Verhandlungsge-

genstand kann sein, dass ich eine Teillieferung oder in einer anderen Qualität leiste,

aber dafür einen Preisnachlass gewähre. Mit dem Auftraggeber kann ich verhandeln,

dass wir bereit sind, dem Kunden eine vertraglich festgelegte Schadensforderung zu

bezahlen (Claim). Oder ich handle aus, dass ich mehr Ressourcen für das Projekt bereit-

gestellt erhalte, um den Vertrag zeitgerecht erfüllen zu können. Die gewählte Strategie

ist abhängig von der Priorisierung der eigenen Ziele und der Einschätzung der Ziele

des Verhandlungspartners (Zielpyramide). Stehen die Kundenbeziehung und die Repu-

tation an erster Stelle, wird eher eine Anpassungs- oder Kooperationsstrategie gewählt.

Stehen eigene ﬁnanzielle Interessen (Deckungsbeitrag, Auftragslage) im Vordergrund,

416

Team

wird zusätzlich auch eine Kompromiss- oder Durchsetzungsstrategie in Kauf genom-

men. Häuﬁg ist es nicht in der Entscheidungskompetenz des Projektleiters, welche

Strategie primär gewählt wird. Durch seine geschickte Vermittlung (Verhandlungskom-

petenz) kann er jedoch herbeiführen, dass die Parteien eher kooperative Strategien zur

Problemlösung wählen.

Taktiken

Wenn die zielführendste Strategie und mindestens ein Plan B für den Fall, dass der Ver-

handlungspartner nicht auf Plan A einsteigt, erarbeitet worden sind, kann die Taktik für

die Verhandlung zurechtgelegt werden. Diese Taktik ist auch abhängig von den Charak-

tereigenschaften der an der Verhandlung beteiligten Personen. Zur Taktik gehören:

Ort, Raum und Zeitpunkt für die Verhandlung

Beteiligte Personen festlegen: Projektleiter oder Product Owner müssen sicherstellen,

dass alle Personen, die Handlungs- oder Entscheidungsfreiheit für die Verhandlungs-

gegenstände haben, in den Prozess eingebunden sind, z. B. Vertreter vom Verkauf,

Auftraggeber oder Linienvorgesetzte.

Mehr fordern, als man will: Um Manövriermasse in der Verhandlung zu haben, wird

am Anfang mehr gefordert, als effektiv benötigt wird.

Wie soll argumentiert werden? Durch welche Begründungen soll die eigene Verhand-

lungsposition untermauert werden?

4.3.3.2

Optimale Verhandlungsstrategie und Taktik: Situativ

Verhandlungen ﬁnden immer zwischen Menschen statt. Diese Menschen stehen zueinan-

der in Beziehung. Die Verhandlungsführung wird stark davon abhängen, wie die Bezie-

hung zu den direkten Verhandlungspartnern (Auftraggeber und Projektleiter) sowie den

indirekt betroffenen Parteien eingeschätzt wird: Handelt es sich um einen nicht-strate-

gischen Kunden, kann ein möglicher Claim das kleinere Übel sein, als wenn von einem

anderen, strategisch wichtigen Kundenprojekt die Ressourcen abgezogen würden. Handelt

es sich bei dem Kunden jedoch um einen strategisch wichtigen Referenzkunden, mit einer

großen Gefahr für den Verlust von möglichen Folgeaufträgen, wird das die Verhandlung

zwischen Auftraggeber und Projektleiter maßgeblich beeinﬂussen.

Aber auch die Beziehung zwischen Auftraggeber und Projektleiter ist relevant: Ar-

beiten die beiden schon seit Jahren zusammen in einem delegativen oder partizipativen

Führungsstil, ist das eine völlig andere Ausgangslage, als wenn der Auftraggeber seinen

Projektleiter autoritär führt und sich nicht scheut, seine institutionellen Machtquellen aus-

zuspielen.

Im ersten Fall, innerhalb der partizipativen Führungsbeziehung zwischen Auftraggeber

und Projektleiter, eignet sich die Verhandlungsführung nach dem Harvard-Konzept. Die-

ses Konzept funktioniert jedoch nicht, wenn eine Partei ihre Macht in der Verhandlung

ausspielt. Für diesen Fall empﬁehlt sich die situative Verhandlungsführung. Die Wahl der

Verhandlungsführung sollte sich stets an folgender Regel orientieren:

4.3

Verhandlungsführung

417

Kooperative, integrative Verhandlung

Verhandlungs-

gegenstand

Faire, gerechte

Verteilung

Neue, zusätzliche

Verhandlungs-

gegenstände

Erweiterte, grössere

Verhandlungsmasse

Konfrontative Verhandlung

Kampf, oft unge-

rechte Verteilung

Abb. 4.17 Kooperative Strategie durch neue Verhandlungsgegenstände nach André Baer

Zu wählen ist stets jene Strategie, die auf eine langfristige Kooperation zielt, unter Wahrung

des eigenen Ansehens (André Baer).

Grundsätzlich können mit einer kooperativen Verhandlungsstrategie langfristig die

besten Ergebnisse erreicht werden. Das bedingt aber, dass die Parteien es schaffen, ihre

unterschiedlichen Interessen zu integrieren. Von dem her sollte diese Strategie als Op-

timum immer die erste Wahl sein. Das bedeutet aber meistens, dass es gelingt, zum

ursprünglichen Verhandlungsgegenstand noch neue, zusätzliche Verhandlungsgegenstän-

de in den Verhandlungsprozess mit einzubeziehen (Abb. 4.17). Bildlich gesprochen geht

es in erster Linie nicht um die Aufteilung eines Kuchens (konfrontative Verhandlung), son-

dern um die Vergrößerung desselben, um so einen zusätzlichen Nutzen für beide Parteien

zu generieren (integrative Verhandlung). Sobald eine Partei anfängt, speziﬁsche Macht-

faktoren zu ihren Gunsten einzusetzen, ist die Integration nicht mehr möglich.

4.3.3.3

Verhandlungsführung

Nach der Vorbereitung kann in die effektive Verhandlungsführung eingestiegen werden.

Diese orientiert sich an drei Phasen:

418

Team

1. Kontakt

Zuerst muss für die Verhandlung ein optimales Gesprächsklima hergestellt werden. Vor

allem die Kompromiss- und Kooperationsstrategie hängen davon ab, ob es den Verhand-

lungsparteien gelingt, Vertrauen zueinander aufzubauen (Abschn. 3.3.7).

Dann ist das Ziel für die Verhandlung zu klären. Auch mögliche Nicht-Ziele sind so-

gleich abzugrenzen. Die Verhandlungsparteien sollen in diesem Schritt ihre Forderungen

und Wünsche einbringen können.

Schließlich wird die Tagesordnung festgelegt: Zeitrahmen, Agenda und Vorgehens-

weise. Auch soll klar sein, welche Kommunikationsregeln gelten und wer die speziﬁschen

Rollen wie Moderation oder Sitzungsleitung bekleidet.

2. Kernphase

Die Kernphase der Verhandlung gliedert sich in drei Abschnitte:

1. Informationsaustausch

Das Thema, das Problem präsentieren

Auswirkungen, Bedeutung, Folgen der Situation für beide Seiten aufzeigen

Gegenseitig dazu Stellung nehmen

2. Verhandlungsspielraum

Verhandlungsspielraum für jeden Punkt ermitteln

Untersuchen, ob sich eine gemeinsame Plattform für Zugeständnisse anbietet

Verhandlungsmasse durch Integration sonstiger Interessen erweitern

3. Lösungssuche

Prioritäten klären

Szenarien und Lösungsvarianten aufzeigen

Mögliche Zugeständnisse austauschen

Nutzen der Ergebnisse bewerten

Entscheid fällen

3. Vereinbarungsphase

Abgeschlossen wird die Phase der Verhandlungsführung durch die Vereinbarungsphase.

Zuerst werden die Ergebnisse und Entscheide der Verhandlung zusammengefasst. Ab-

schließend wird die Verbindlichkeit für die Umsetzung durch einen Vertrag oder ein Pro-

tokoll hergestellt.

1. Zusammenfassung und Ausblick

Ergebnisse zusammenfassen

Überprüfen, dass keine Missverständnisse vorliegen

Ziele und Zeitplan für die Umsetzung vereinbaren

Maßnahmen besprechen und einleiten

2. Vereinbarung, Vertrag

Ergebnisse schriftlich festhalten

4.3

Verhandlungsführung

419

Auf weitere Schritte einigen

Festhalten, was bei Nichteinhaltung der Vereinbarung geschieht

Nachfolgetermin vereinbaren

Den Verhandlungspartnern danken

4.3.3.4

Auswertung und Controlling

Wie ein Projekt wird auch eine Verhandlung ausgewertet. Die eigene Verhandlungsfüh-

rung – und damit die gesamte Vorbereitung mit dem Festlegen von Strategie und Taktik

– ist zu analysieren und mögliche Maßnahmen für die Zukunft abzuleiten. Zudem muss

im Sinne eines Controllings sichergestellt werden, dass die vereinbarten Maßnahmen von

allen Verhandlungsparteien entsprechend umgesetzt werden.

4.3.4

Verhandlung nach dem Harvard-Konzept führen

Die Verhandlungsführung nach dem Harvard-Konzept (Fisher et al. 1999) ist eine koope-

rative Verhandlungsstrategie. Mit diesem Ansatz können unter folgenden Grundbedingun-

gen optimale Verhandlungsergebnisse erreicht werden:

Die Parteien haben Spielräume, die sich gegenseitig überlappen.

Die Parteien setzen bewusst ihre Machtfaktoren nicht ein.

Die Parteien verfügen über eine hohe kommunikative Kompetenz und legen ihre Infor-

mationen offen.

Unter diesen Prämissen eignet sich das Harvard-Konzept auch gut in der Bewältigung

von Konﬂiktsituationen. In Abschn. 4.4.10.4 wird die Konﬂiktbewältigung nach diesem

Konzept vorgestellt.

4.3.4.1

Trennung zwischen Person und Sache

Das Harvard-Konzept ist bekannt geworden mit dem Satz „Hart in der Sache, weich ge-

genüber den Menschen“. Die Essenz des Modells bilden die in Abb. 4.18 dargestellten

Schlüsselfaktoren. Solange sich alle Konﬂiktparteien auf Augenhöhe begegnen, die In-

tegration der Interessen im Mittelpunkt steht und keine institutionellen Machtfaktoren

wie Positionsmacht, Entscheidungsmacht oder Macht durch Bestrafung (Abschn. 4.1.3)

eingesetzt werden, können damit die besten Resultate erreicht werden (Fisher et al. 1999).

Der Verhandlungsinhalt ist klar von der Person zu trennen. Ob uns die andere Person

sympathisch ist oder nicht, soll keinen Einﬂuss haben auf unsere Verhandlung. Wie im

Sport geht es darum, während der Verhandlung inhaltlich engagiert zu streiten. Danach

gibt man sich mit Respekt die Hand. In Verhandlungen bedeutet das:

420

Team

Sache

Person

Interessen

Nicht Positionen,

sondern Interessen

in den Mittelpunkt

stellen

Kriterien

Das Ergebnis

auf objektive

Entscheidungs-

prinzipien aufbauen

Möglichkeiten

Vor der Entscheidung

verschiedene Wahl-

möglichkeiten

entwickeln

Menschen

Menschen und

Probleme getrennt

voneinander

behandeln

«Hart in der Sache, weich gegenüber den Menschen»

Abb. 4.18 Schlüsselfaktoren im Harvard-Konzept

Vertrauen schaffen: Es wird ein „Verhandlungsraum“ benötigt, in welchem sich alle

Parteien sicher fühlen.

Rollen und Verantwortlichkeiten der in den Prozess involvierten Personen (Parteien)

klären.

Kommunikationsregeln klären: Ich-Botschaft, aktives Zuhören, ausreden lassen sowie

keine Annahmen treffen zu den Absichten des anderen, sondern nachfragen.

4.3.4.2

Interessen anstatt Positionen

Im nächsten Schritt löst man sich von den Positionen. Die Position beschreibt das, was wir

zu wollen vorgeben. Das kann der Kampf des Projektleiters mit seinem Auftraggeber sein

für mehr Ressourcen. In der Position gibt es immer einen Schwächeren (in diesem Fall der

Projektleiter) und einen Stärkeren (Auftraggeber). In dieser Konstellation ist es schwierig,

eine Einigung zu erreichen. Wenn es dem Projektleiter gelingt, bei seinem Auftraggeber

ein Commitment für ein gemeinsames Interesse zu erreichen, kann die Verhandlung auf

Augenhöhe geführt werden. Der Blick geht von der Gegenwart in die Zukunft:

4.3

Verhandlungsführung

421

Gemeinsame Interessen und Bedürfnisse in den Mittelpunkt stellen. Das können Ri-

siken sein, die eliminiert werden sollen, qualitative Aspekte oder auch gemeinsame

Interessen in Bezug auf die Projektdauer.

Perspektivenwechsel: Um gemeinsame Interessen zu ﬁnden, muss ich mich fragen kön-

nen, was der Verhandlungspartner von mir braucht und mit welchen Schwierigkeiten

oder Einschränkungen dieser konfrontiert ist.

Für den Perspektivenwechsel von der Position zu den Interessen und auch Be-

dürfnissenistderMetamirrornachRobertDiltsoderdieKonfliktzwiebelhilfreich

Abschn. 4.4.10.4.

4.3.4.3

Kriterien

Vor der effektiven Beurteilung der Varianten werden die Entscheidungskriterien lösungs-

neutral und so gut und SMART (Abschn. 2.3.2.4) wie möglich festgehalten. Die gemein-

same Diskussion objektiver Kriterien, die für die Auswahl der Verhandlungsalternative

angewendet werden können, erleichtert es, Positionen zu verlassen. Auch entzieht sie un-

fairem Druck von beiden Seiten die Grundlage. Häuﬁge Kriterien sind:

Ein Kostendach, welches nicht überschritten werden darf.

Speziﬁsche Risiken, die reduziert werden müssen.

Meilensteine, die eingehalten werden müssen.

4.3.4.4

Möglichkeiten

Je mehr Varianten in einer Verhandlung zur Verfügung stehen, desto größer ist der Spiel-

raum für den Entscheid. In dieser Phase geht es darum, verschiedene Möglichkeiten zu

erarbeiten, die die Aspekte der erarbeiteten Interessen und Bedürfnisse erfüllen. Das heißt:

Realistische Möglichkeiten entwickeln: Die beste Lösung ist meistens allen klar, nur

ist sie nicht realistisch, weil alle Organisationen, die Projekte abwickeln, sich im-

mer in einem Balance-Akt beﬁnden zwischen den Elementen des magischen Dreiecks

„Scope“, „Zeit“ und „Kosten“. Also ist die zweitbeste Lösung zu entwickeln.

Neben der optimalen Variante weitere Alternativen ausarbeiten. Es braucht mindes-

tens einen Plan B, besser noch weitere Möglichkeiten und Varianten.

Verhandlungsparteien für die Entwicklung möglicher Lösungsansätze aktiv einbinden.

Damit wird die Verbindlichkeit in der späteren Umsetzung höher sein.

Verschiedene Möglichkeiten zu entwickeln braucht Kreativität.

4.3.4.5

Auswahl nach dem BATNA-Prinzip

Wenn diese vier Aspekte berücksichtigt worden sind, kann die beste Lösungsalterna-

tive gewählt werden. Dies sollte in Berücksichtigung des BATNA-Prinzips geschehen:

Best Alternative to a Negotiated Agreement. Der Mensch ist in Entscheidungssituatio-

nen immer auch beeinﬂusst durch seine Gefühle, persönliche Ziele und die Intuition. Um

sicherzustellen, dass die Vernunft und der Verstand adäquat berücksichtigt werden, emp-

ﬁehlt es sich hier, Entscheidungstechniken anzuwenden (Abschn. 2.8.2).

422

Team

4.4

Konfliktmanagement und Krisen

Das Bestehen von Differenzen ist nicht das Problem. Differenzen machen an sich noch keinen

Konﬂikt aus. Es kommt einzig darauf an, wie die Menschen die Differenzen erleben und wie

sie mit ihnen umgehen (Friedrich Glasl).

Konﬂikte gehören grundsätzlich zum menschlichen Miteinander. Der Mensch ist von Na-

tur aus expansiv. Das heißt er will seine Umwelt gestalten und seine Überzeugungen

verwirklichen. Mit dieser Haltung kommt er zwangsläuﬁg seinen Mitmenschen in die

Quere. So sind in der Projektarbeit mit interdisziplinären Teams unter Zeitdruck und mit

begrenzten Mitteln ambitionierte Ziele zu erreichen. Gerade in Teams, in denen mit viel

Einsatz und Herzblut gearbeitet wird, prallen immer wieder unterschiedliche Überzeu-

gungen aufeinander. Das hat Differenzen zur Folge. So gesehen ist der Ursprung von

Konﬂikten in Projekten oft etwas Positives: Stakeholder oder Projektverantwortliche, die

sich mit Engagement für ihre Überzeugung oder für ihren Auftraggeber einsetzen.

Diese Rahmenbedingungen verursachen die Differenzen geradezu und erzeugen eine

Spannung auf die Elemente des magischen Dreiecks: „Scope“, „Zeit“ und „Ressourcen“

(Abschn. 2.3.4). Damit gehört das Konﬂiktmanagement zu den Kernkompetenzen in der

Projektarbeit.

Nach Glasl ist nicht die Differenz, sondern die Art und Weise, wie damit umgegan-

gen wird, das Problem. Um mit Konﬂikten konstruktiv umgehen zu können, dürfen sie

nicht als bedrohlich oder als Konsequenz von Fehlern bewertet werden, sondern als natür-

liche Konsequenz der Rahmenbedingungen der Projektarbeit. Aus dieser Haltung heraus

wird der Konﬂikt diagnostiziert. Der Konﬂikt muss erkannt und in seiner Komplexität

verstanden werden. So kann man sich in einer konstruktiven Art und Weise mit ihm

auseinandersetzen (Lippmann 2008, S. 316). Die Konﬂiktbewältigung zielt darauf, die

Menschen in ihren Zielsetzungen wieder handlungsfähig zu machen. Dies ist nur möglich,

wenn es den betroffenen Parteien gelingt, ihren allfälligen Affekt hinter sich zu lassen und

in die Kognition zu gelangen. Vorschläge zur Konﬂiktprävention und der Umgang mit

Krisen in Projekten runden das Kapitel ab.

Der größte Teil dieses Kapitels gilt für das klassische wie auch auf das agile Projekt-

management. Einzig das Thema Konﬂiktarten wird differenziert betrachtet.

4.4.1

Was ist ein Konflikt?

Im deutschsprachigen Raum wird die Deﬁnition von Friedrich Glasl (2008, S. 24) viel

zitiert:

Ein sozialer Konﬂikt ist eine Interaktion

zwischen Aktoren (Individuen, Gruppen, Organisationen usw.),

wobei wenigstens ein Aktor

4.4

Konfliktmanagement und Krisen

423

Differenzen (Unterschiede, Widersprüche, Unvereinbarkeiten)

im Wahrnehmen

und im Denken/Vorstellen/Interpretieren

und im Fühlen

und im Wollen

mit dem anderen Aktor (den anderen Aktoren) in der Art erlebt,

dass beim Verwirklichen dessen, was der Aktor denkt, fühlt oder will,

eine Beeinträchtigung durch einen anderen Aktor (die anderen Aktoren) erfolgt.

In dieser Deﬁnition bezieht sich Glasl auf den sozialen Konﬂikt. Er impliziert damit

also, dass Konﬂikte immer zwischen mindestens zwei Menschen oder Gruppen auftreten.

Darin erlebt mindestens eine Partei Differenzen in ihrem Denken, Fühlen oder Wollen

gegenüber einer anderen Partei, sodass diese sich beeinträchtigt fühlt.

Zum Vergleich hier die Deﬁnition von Karl Berkel (2014, S. 11):

Ein Konﬂikt liegt dann vor, wenn zwei Elemente gleichzeitig gegensätzlich oder unvereinbar

sind.

Durch den neutralen Begriff „Elemente“ kommt zum Ausdruck, dass unterschiedliche

Inhalte eine Konﬂiktsituation verursachen können:

Gedanken: Weshalb bekomme ich von meinem Projektleiter keine Anerkennung?

Wünsche: Ich möchte die Rolle eines Product Owners übernehmen und trotzdem in

einem freundschaftlichen Verhältnis zum Team stehen.

Verhalten: Ich erwarte von meinem Auftraggeber regelmäßige Unterstützung, bin aber

wenig für mein Team da.

Beurteilungen: Der Projektausschuss ﬁndet, dass der Projektleiter eines Akzeptanzpro-

jektes eine hohe Sozialkompetenz braucht – der Auftraggeber ﬁndet, dass vielmehr die

Projekterfahrung und die Fachkompetenz wichtig sind.

Personen: Zwei Mitglieder des Projektteams empﬁnden eine starke Abneigung oder

Antipathie zueinander und weigern sich, zusammenzuarbeiten.

Gruppen: Die Kundenbetreuer stehen im Zwist mit den Projektverantwortlichen, weil

diese die Termine nicht einhalten können. Die Projektverantwortlichen werfen den

Kundenbetreuern vor, unrealistische Termine in die Verträge zu nehmen.

Die Konﬂiktdeﬁnitionen von Berkel und Glasl stimmen in folgenden Punkten überein:

Konﬂikte sind Störungen

Konﬂikte reißen uns aus den gewohnten Mustern des Denkens, Fühlens und Handelns

heraus. Wir nehmen Konﬂikte zuerst als eine Störung wahr. Etwas ist nicht so, wie wir es

erwartet haben. Wir fühlen uns in unserem Handeln beeinträchtigt.

424

Team

Konﬂikte sind emotional

Dadurch, dass wir uns durch eine Störung beeinträchtigt fühlen, entwickeln wir Emotio-

nen. Wir empﬁnden die Situation als unangenehm, fühlen uns enttäuscht oder vielleicht

verletzt. Anspannung macht sich breit, begleitet von Angst oder Ärger.

Konﬂikte erfordern eine Intervention

Differenzen sind die natürlichste Sache der Welt. Über Meinungsverschiedenheiten kann

man argumentieren und debattieren. Konﬂikte sind Situationen, in denen ein Einigungs-

zwang besteht. Es muss eine Intervention stattﬁnden, damit die Beeinträchtigung, in wel-

cher sich mindestens eine Partei erfährt, so weit aufgelöst werden kann, dass deren Hand-

lungsfähigkeit wieder sichergestellt ist.

4.4.2

Ursprung und Symptom: Das systemische Phänomen

Die meisten Konﬂikte äußern sich am Anfang als persönliche (seelische) oder zwischen-

menschliche Konﬂikte.

Beim persönlichen Konﬂikt liegt die Störung im Menschen selber. Seine Gedanken

oder Wünsche stehen im Widerspruch zueinander.

Im zwischenmenschlichen Konﬂikt manifestiert sich die Störung im Verhalten oder in

der Eigenart einer anderen Person oder Gruppe: Man verspürt eine Abneigung zu einem

anderen Menschen, möglicherweise begründet in unterschiedlichen Werten, Überzeu-

gungen oder Haltungen. Manchmal ist der Grund nicht einmal ersichtlich. Es ist dann

einfach die Chemie, die nicht stimmt. Oder aber die Störung liegt nicht in der anderen

Person selber, sondern in deren Verhalten. Wir fühlen uns dadurch beeinträchtigt.

In der Projektarbeit können an vielen Stellen Störungen auftreten, nur schon, weil die

Einﬂussfaktoren des magischen Dreiecks zueinander im Widerspruch stehen. Auch gibt

es unterschiedliche Überzeugungen in Bezug auf die optimale Projektmethodik (klassisch,

hybrid, agil). Oder die persönliche Projekt- und Linienarbeit lassen sich nicht vereinba-

ren. Alle diese unvereinbaren Elemente bleiben nicht auf dem Papier allein: Sie führen

dazu, dass jeder Mensch sein Fühlen, Denken oder Handeln nach den persönlichen Über-

zeugungen und Beurteilungen ausrichtet. Damit verlagert sich der Konﬂikt von seinem

Ursprung – der Unvereinbarkeit zwischen Linien- und Projektarbeit – hin zum Symp-

tom: der Beziehung zu sich selber oder zu den anderen Menschen.

Ein Projektleiter hat mit seinem arbeitspaketverantwortlichen Experten die

Aufgaben detailliert besprochen sowie die Aufwände und auch die Abgabe-

termine vereinbart. Wiederholt kann der Experte seinen Verpflichtungen nicht

nachkommen. Immer wieder wird dieser durch seinen Linienvorgesetzten auf

andere Projekte mit höherer Priorität angesetzt. Am Anfang handelt es sich um

4.4

Konfliktmanagement und Krisen

425

einen organisatorischen Konflikt: Der Linienvorgesetzte hält sich nicht an die

Abmachung mit dem Projektleiter, und es besteht keine Ressourcenplanung

zwischen Linie und Projekt. Nach der zweiten oder dritten Verschiebung ist die

Wahrscheinlichkeit groß, dass der Projektleiter das Versäumnis seines Experten

„persönlich“ nimmt. Er fühlt sich nicht respektiert in seiner Rolle, vielleicht sogar

hintergangen. Das macht etwas mit seinen Gefühlen zu seinem Projektmit-

arbeiter. Der Projektleiter könnte eine heftige Gefühlserregung gegen seinen

Mitarbeiter auslösen und damit die Beziehung beeinträchtigen. In einer ande-

ren Arbeitssituation hätten die beiden Personen vielleicht sehr gut kooperieren

können. Nun aber ist der Experte Symptomträger eines organisatorischen Kon-

flikts.

Dieses Beispiel basiert auf den Ebenen der Zusammenarbeit (Abschn. 1.5). Die meisten

Konﬂiktursachen in Projekten resultieren aus der inhaltlichen oder der organisatorischen

Ebene. Ein wesentlicher Zweck der gesamten Projektmanagement-Methodik in Kap. 2

liegt darin, dass mögliche Konﬂiktpotenziale aktiv erkannt und geklärt werden: Über die

Projektorganisation werden Aufgaben und Kompetenzen festgelegt. In einer RACI-Ma-

trix (Abschn. 2.3.9.9) wird deﬁniert, wer in welchem Arbeitspaket was zu tun hat. Ein

Informationskonzept zeigt, wer von wem in welcher Form über was informiert wird usw.

All das dient dazu, mögliche Störungen in der Projektorganisation zu verhindern.

1. Phase des systemischen Phänomens

Je weniger gut der methodische Ansatz angewendet wird, desto höher ist das Konﬂiktpo-

tenzial. Die nicht geklärten Aufgaben und Kompetenzen stellen ein Versäumnis auf der

organisatorischen Ebene dar. Manifestieren werden sie sich jedoch in Störungen auf der

Beziehungsebene, weil zwischen den Projektbeteiligten resp. deren Linienvorgesetzten

unterschiedliche Erwartungen bestehen. In einer ersten Phase verlagert sich der Konﬂikt

vom Inhalt und der Organisation zur Beziehung, siehe Abb. 4.19.

Der Konﬂikt wird damit vom Linienvorgesetzten in die Beziehung zwischen dem Pro-

jektleiter und dem Experten „delegiert“. Wenn den Beteiligten und Verantwortlichen in

Projekten nicht bewusst ist, dass sie Symptomträger von delegierten Konﬂikten sein

können, werden sie diese Störungen immer mehr auf sich selber beziehen. Wir Autoren

bezeichnen dies als „systemisches Phänomen“.

I System Das Wort „System“ stammt aus dem Griechischen. Im Deutschen bedeutet es

„zusammen + stehen“. Eine systemische Grundhaltung versucht, ein Ganzes immer im

Zusammenwirken der einzelnen Teile zu erfassen (Königswieser und Hillebrand 2004,

S. 22).

Wer das systemische Phänomen kennt, stellt im Konﬂiktfall nicht vorschnell die Be-

ziehungsebene als Konﬂiktgrund in den Mittelpunkt, sondern versteht den Friktionspunkt

als Symptom. Er deckt die Dynamiken, Kräftefelder, Widersprüche und Deﬁzite auf, die

den Konﬂikt ursächlich antreiben.

426

Team

Beziehung

Inhalt

Organisation

Abb. 4.19 Erste Phase des systemischen Phänomens im Konﬂikt

2. Phase des systemischen Phänomens

Auf der Beziehungsebene sind zwei Optionen möglich: Die Spannung manifestiert sich

nach außen in der Beziehung zu den Mitarbeitern als sozialer Konﬂikt oder nach innen als

persönlicher Konﬂikt.

Beispiel

Gibt es in einer Organisation keinen etablierten Change Request Management Pro-

zess (Abschn. 2.5.8.2), wird der Projektleiter immer wieder vor dem intrapsychischen

Konﬂikt stehen, wie er mit der schleichenden Veränderung des Leistungsumfangs

(Scope Creeping) umgeht. Ohne irgendetwas falsch gemacht zu haben, steckt der Pro-

jektleiter in einem Vermeidungs-Vermeidungskonﬂikt (Abschn. 4.4.7.6). Weist er die

Anforderung zurück, brüskiert er den Stakeholder, der den Antrag stellt. Das ist bei ei-

nem Kunden oder Auftraggeber sehr schwierig bis hin zu unrealistisch. Nimmt er den

Antrag an, ohne dass die Konsequenzen des Antrages adäquat in Projektplanung und

Budget Niederschlag ﬁnden, konfrontiert sich der Projektleiter selber wie auch sein

Team mit zusätzlichen Aufwänden, höheren Risiken und neuen Dilemmata, weil dazu

andere Aufgaben von der Priorität her zurückgestellt werden müssen.

4.4

Konfliktmanagement und Krisen

427

In dieser Situation stehen zwei unterschiedliche Möglichkeiten zur Verfügung:

1. Konﬂiktmanagement ﬁndet statt

Die bewusste Auseinandersetzung zwischen Symptom und Ursache ﬁndet statt. Die Be-

ziehungsebene wird geschützt, der Konﬂikt wird zurückgewiesen. Das heißt die Delegati-

on wird nicht übernommen und an ihren Ursprung zurückgewiesen, wo die Ursachen so

gut wie möglich bewältigt werden.

Beispiel

Der Projektleiter geht nicht in die Haltung des „Vorauseilenden Gehorsams“ und ist be-

strebt, die Situation zu verändern. Er speziﬁziert den Änderungsantrag nach den Regeln

des Change Request Managements Abschn. 2.5.8.2. Damit fordert er seinen Auftrag-

geber heraus, eine klare Stellung zu beziehen, und geht natürlich auch das Risiko ein,

dass seine Intervention auf irgendeine Art sanktioniert wird.

2. Konﬂiktmanagement ﬁndet nicht statt

In diesem Fall kann der Konﬂikt meistens nicht auf der Beziehungsebene thematisiert

werden, weil die Parteien schon in einem Affekt zueinander stehen. Die Gefahr ist groß,

dass der Konﬂikt auf der Beziehungsebene verdrängt wird. Da der Affekt zwischen den

Betroffenen aber bestehen bleibt, werden sie sich in inhaltlichen oder organisatorischen

Fragen immer wieder Debatten lieferen.

Beispiel

Der Projektleiter getraut sich nicht, beim Auftraggeber zu intervenieren. Er versucht,

die zusätzlichen Anforderungen innerhalb der bestehenden Zeit- und Ressourcenbud-

gets zu realisieren. Damit vermeidet er das Risiko eines Disputs mit dem Vorgesetzten.

Die Projektrisiken als Ganzes nehmen aber zu, da mehr Komplexität bewältigt werden

muss. Zudem steigen die Risiken, dass es Spannungen geben wird innerhalb des Pro-

jektteams (soziale Konﬂikte), wie auch, dass das persönliche Selbstmanagement unter

dieser Situation leidet.

4.4.3

Konfliktsyndrom

Konﬂikte sind meistens nicht urplötzlich in ihrer vollen Intensität da. Je länger sie sich

auf der Beziehungsebene manifestieren und nicht bearbeitet werden, desto mehr intensi-

vieren sie sich. In Abb. 4.20 sind die folgenden Einﬂussfaktoren dargestellt, die auch als

Konﬂiktsyndrom bekannt sind.

428

Team

Kommunikation

lässt nach oder

ist unaufrichtig

Wahrnehmung

ist verzerrt

oder polarisiert

Einstellung ist

von Misstrauen

beherrscht

Gemeinsames

Ziel wird aus

den Augen

verloren

Abb. 4.20 Konﬂiktsyndrom. (Berkel 2014, S. 65)

Kommunikation lässt nach oder ist unaufrichtig

Informationen werden kaum oder fehlerhaft ausgetauscht

Es wird mehr übereinander als konkret über die Thematik gesprochen

Verdeckte Drohungen und offener Druck treten an die Stelle von Argumenten und

Überzeugungskraft

Wahrnehmung ist verzerrt und polarisiert

Unterschiedliche Interessen, Meinungen und Überzeugungen werden schärfer wahrge-

nommen

Die Differenzen untereinander gelten als bedeutsamer als die (noch) vorhandenen Ge-

meinsamkeiten

Versöhnliche Gesten werden als heuchlerisch, humorvolle Bemerkungen als zynisch

und sachliche Absichten als feindselig interpretiert

4.4

Konfliktmanagement und Krisen

429

Einstellung ist von Misstrauen beherrscht

Die Bereitschaft sinkt, andere zu unterstützen

Die Fähigkeit und Bereitschaft lassen nach, andere zu verstehen und sich in sie einzu-

fühlen

Die Neigung nimmt zu, einander persönlich zu verletzen

Gemeinsame Ziele verwässern

Jeder versucht, seine Ziele auf Kosten der anderen zu erreichen

Gegenseitige Behinderungen nehmen zu

Abstimmung (Koordination) und Arbeitsteilung unterbleiben, dadurch kommt keine

Synergie zustande

4.4.4

Konfliktsymptome

Gemäß dem systemischen Phänomen verlagern sich Widersprüche und Dysfunktionalitä-

ten von der inhaltlichen und der organisatorischen Projektebene auf die Beziehungen. Das

bewirkt beim Menschen als Symptomträger der Konﬂikte eine Veränderung in seinem

Fühlen, Denken und Handeln. Für andere wahrnehmbar ist vordergründig das Handeln.

Die in Tab. 4.12 aufgeführten Symptome können auf Konﬂikte hinweisen.

4.4.5

Potenzial von Konflikten

Oft werden Konﬂikte nur negativ konnotiert und als Störung wahrgenommen, die das

Erreichen der Projektziele verhindern oder verzögern. Ist dies der Fall, werden sie zu

Tab. 4.12 Konﬂiktsymptome

Ablehnung, Wider-

stand

Ständiges Widersprechen, „Ja, aber“-Verhalten, mürrische Reaktionen

Aggressivität,

Feindseligkeit

Verletzende Reden, „böse“ Blicke, abwertende Bemerkungen, absichtliche

Fehler, „Mauern“, Sabotage

Sturheit, Uneinsich-

tigkeit

Rechthaberisches Verhalten, „Kleben“ an Vorschriften, „das funktioniert

so nicht bei uns, ...“

Flucht

Kontakte vermeiden, aus dem Weg gehen, Wortkargheit, innerer Rückzug,

Ausweichen auf andere Themen

Überkonformität

Keine eigenen Ideen einbringen, Kritik vermeiden, sich den anderen Mei-

nungen anschließen

Desinteresse

Formelle Höﬂichkeit, sich zurückziehen, passive Arbeitshaltung, Ignoranz

Formalität

Dienst nach Vorschrift, Weisungen genau einhalten, alle Schritte schrift-

lich festhalten und dies von den andern ebenso erwarten

430

Team

Tab. 4.13 Positive und negative Eigenarten von Konﬂikten. (Abgeleitet von Lippmann 2008,

S. 318)

Positiv

Negativ

Erlaubt, die eigene Persönlichkeit zu entwi-

ckeln

Verletzt die persönlichen Grundbedürfnisse

Hilft, die eigenen Grenzen zu schützen

Führt in die Isolation

Verweist auf Probleme

Fördert den Widerstand

Verhindert Stagnation, ist Wurzel für Verände-

rungen

Entzieht der Hauptaufgabe den Fokus, blo-

ckiert Energie

Stimuliert Ideen

Bindet wertvolle Ressourcen

Regt Interesse und Neugierde an

Weckt Angst, Wut, Frustration, Schmerz, Stress

und Unzufriedenheit

Verhilft zu Lösungen

Verwirrt Mitarbeiter

Ermöglicht eine Gegenüberstellung aus Selbst-

bild und Fremdbild

Begünstigt Schuldzuweisungen

Führt zu Selbsterkenntnis der Persönlichkeit

Hinterlässt Gewinner und Verlierer

einer Bedrohung oder Verletzung und können Angst machen. Damit werden Konﬂikte

intensiver. Ihr Potenzial wird nicht genutzt und die Involvierten können sich nicht (wei-

ter)entwickeln.

Der primäre Nutzen von Konﬂikten ist, dass sie Indikatoren dafür sind, dass zwei Ele-

mente gegensätzlich oder unvereinbar sind und somit die Aufmerksamkeit der involvierten

Personen benötigen.

Das Gegenteil wäre schlecht: Wenn in einem Projektteam oder in dessen Stammorgani-

sation eine „friedhöﬂiche“ Atmosphäre herrscht, in der alle nett zueinander sind, werden

die unterschiedlichen Überzeugungen nicht mehr thematisiert. In der hohen Komplexität

und unter den anspruchsvollen Rahmenbedingungen, welche die Projektarbeit heute prä-

gen, ist es unmöglich, dass ein „Master Mind“ alles überschaut und den „Magic Code“

hat, alle Probleme zu lösen.

Die Projektarbeit ist darauf angewiesen, dass Differenzen und Konﬂikte immer wieder

im Sinne der Projektziele konstruktiv bearbeitet werden, um gemeinsam an der Heraus-

forderung zu wachsen. Natürlich haben alle schon negative Erfahrungen gemacht mit

Konﬂikten. Natürlich können Konﬂikten immer negative Konsequenzen zugeschrieben

werden. Aber sie beinhalten auch viel positives Potenzial, wie in Tab. 4.13 ersichtlich ist.

4.4.6

Was passiert bei Konflikten in unserem Gehirn?

4.4.6.1

Erregung im Gehirn

Wann haben wir hirntechnisch einen Konﬂikt? Grundsätzlich passiert das immer dann,

wenn wir aus unserem Bewusstsein eine bestimmte Erwartungshaltung an eine Situation

generieren, die dann nicht erfüllt wird. Wenn z. B. der Projektleiter zu einer für ihn wich-

4.4

Konfliktmanagement und Krisen

431

tigen Meilensteinsitzung einlädt, erwartet er, dass alle Eingeladenen pünktlich erscheinen

und die Unterlagen studiert haben. Wenn dann gewisse Personen zu spät kommen oder

überhaupt nicht vorbereitet sind, gerät sein Hirn in den Zustand der Erregung. Es entsteht

eine Unordnung, welche zu einer Stressreaktion führen kann.

Was jetzt passiert, vergleicht der Hirnforscher Gerald Hüther (Ballreich und Hüther

2009) mit einer Gruppe Menschen, die in einem Park spazieren. Solange alles ruhig ist,

schaut man aufeinander und nimmt Rücksicht. Plötzlich knallt es irgendwo, die Leute

erschrecken und rennen wild durcheinander. Dieser Knall ist die nicht eingetroffene Er-

wartungshaltung. Wird das Ereignis vom Hirn als bedrohlich bewertet, gerät es in eine

Erregung. In diesem Zustand sind unsere höheren Hirnfunktionen im präfrontalen Kortex

nicht mehr benutzbar (Abschn. 3.3.2).

4.4.6.2

Verlust von Selbstreflexion und Selbststeuerung

Mit dem Ausfall des präfrontalen Kortex verliert der Mensch seine Fähigkeit zur Selbst-

reﬂexion und sogar seine Selbststeuerung. Ohne Selbstreﬂexion ist der Mensch sich nicht

mehr bewusst, wie er sich verhält und was sein Verhalten bei anderen Personen bewirkt.

Und ohne vernunftbasierte Selbststeuerung geht die Reise wie im Fahrstuhl nach unten

(Abb. 4.21): Ältere Bereiche im Hirn, die stabiler sind, übernehmen die Verhaltenssteue-

Ärger ► Angriff

Angst ► Flucht

Ohnmächtiges Erstarren

Antrainierte Verhaltensmuster

Verinnerlichte Lebenser-

fahrung, Werte, Überzeugun-

gen, kognitive Fähigkeiten

Intensität Konﬂikt

Abb. 4.21 Fahrstuhl nach unten. (Basierend auf Ballreich und Hüther 2009)

432

Team

Tab. 4.14 Grundemotionen im Konﬂikt. (Berkel 2014, S. 114)

Angst ! Flucht

Ärger ! Kampf

Angst macht sich leicht breit, wenn ich ...

– angegriffen werde

– mit Mächtigeren zusammenstoße, die ihre

Überlegenheit drohend ausspielen

– mich unsicher fühle

– unvorbereitet bin

Ärger entsteht, wenn ein anderer mich ...

– behindert, indem er Regeln verletzt

– unfair behandelt

– öffentlich beschämt

– ungerechtfertigt beschuldigt

Angst äußert sich körperlich als Schwitzen,

Zittern, Herzklopfen, heisere Stimme. Das Blut

„gefriert“, schießt in die Füße

! ﬂiehen: abwenden oder wegrennen

Ärger äußert sich körperlich in erhöhtem Ad-

renalinausstoß, Lautstärke, Drohgebärden. Das

Blut „kocht“, schießt in die Hände

! kämpfen: zuschlagen oder abwehren

rung. Zunächst sind dies die in der Kindheit antrainierten Verhaltensmuster. Der erwach-

sene Mensch versucht mit den Bewältigungsstrategien, die er schon als Kind erfolgreich

angewendet hatte, die neue Situation zu bewältigen.

Ist die Erregung noch stärker, funktionieren auch die frühkindlichen Strategien nicht

mehr. Der Fahrstuhl geht noch weiter hinunter. Die archaischen Notprogramme kom-

men zur Anwendung. Die Grundemotionen Angst oder Ärger dominieren. Beides sind

unangenehme Gefühle. Die Auswahl reduziert sich auf die Überlebensprogramme Flucht

oder Kampf, wie in Tab. 4.14 dargestellt (Berkel 2014, S. 114). Führt auch das zu kei-

ner Verbesserung der Situation, wird die letzte Stufe des Notprogramms aktiviert: Das

ohnmächtige Erstarren. In diesem Zustand geht gar nichts mehr.

In speziﬁschen Stress- und Bedrohungssituationen haben die archaischen Notfallpro-

gramme durchaus den Nutzen des Selbstschutzes. Aber es wird auch viel Schaden ange-

richtet, weil der Mensch kopﬂos unterwegs ist.

4.4.6.3

Konflikte verletzen die Grundbedürfnisse des Menschen

In Abschn. 3.3.3 ist ausgeführt, dass das Verhalten des Menschen aufgrund seiner Grund-

bedürfnisse zielorientiert ist. Ungestillte Grundbedürfnisse oder Sehnsüchte des Men-

schen führen immer in der einen oder anderen Art zu Konﬂikten. Der Mensch erlebt sich

dann in einer Diskrepanz zwischen dem, was er erwartet, und den Umständen, in denen er

sich effektiv erlebt. Konﬂikte können folgende Grundbedürfnisse bedrohen:

Geborgenheit und Zuwendung: Da sich die Konﬂikte immer auf der Beziehungsebene

manifestieren, bedrohen sie damit auch das Grundbedürfnis nach Zugehörigkeit zur

jeweiligen Gruppe oder Person, mit welcher die Störung auftritt.

Soziale Anerkennung und soziale Stellung: Wer Konﬂikte negativ konnotiert, erwartet

Gewinner und Verlierer. Natürlich will niemand als Verlierer wahrgenommen werden,

weil dies seine Anerkennung oder soziale Stellung bedrohen würde.

4.4

Konfliktmanagement und Krisen

433

Selbstentfaltung: Jeder Mensch möchte seine Fähigkeiten und Überzeugungen zum

Ausdruck bringen. Steht die eigene Überzeugung einer oder mehreren anderen gegen-

über, wird dies als Einschränkung der persönlichen Selbstentfaltung wahrgenommen.

Streben nach Leistung: Konﬂikte als Störungen verlangsamen oder stoppen sogar unse-

ren Arbeitsfortschritt. Man muss sich vom Inhalt und der vordergründig „produktiven“

Arbeit abwenden, um den zwischenmenschlichen Konﬂikt zu bearbeiten.

Existenzielle Sicherheit: Möglicherweise bedrohen Konﬂikte sogar die existenzielle

Sicherheit, wenn ein Konﬂikt derart eskaliert oder zumindest subjektiv als derart be-

drohlich wahrgenommen wird, dass der eigene Arbeitsplatz dadurch gefährdet ist.

4.4.6.4

Konflikte tun weh

Die Neurobiologie konnte mittlerweile durch Hirnscans nachweisen, was mit einem Men-

schen passiert, der aus einer Gemeinschaft ausgeschlossen wird: dieselben Bereiche wer-

den aktiviert, die aktiviert sind, wenn dem Menschen körperliche Schmerzen zugefügt

werden: das Schmerzareal. Das Hirn benutzt für die Wahrnehmung und Verarbeitung von

sozialem Schmerz dieselben Strukturen wie für den Umgang mit körperlichen Schmerzen

(Ballreich und Hüther 2009). Die Volksweisheit „Trennung tut weh“ ist neurobiologisch

bestätigt.

Dabei bleibt es aber nicht: Nach Gerald Hüther schlagen sich Belastungssituationen

immer auch auf einer körperlichen Ebene nieder. Durch die sogenannten somatischen

Marker führt der mentale Schmerz zu einem physischen Schmerz, sei es beispielsweise

im Bauch oder im Herzen, wo sich vor allem die Beziehungsprobleme niederschlagen

(Ballreich und Hüther 2009).

4.4.7

Konfliktarten im Projektmanagement

In Konﬂikten besteht die Gefahr, dass sie vorschnell personiﬁziert werden: Das heißt die

Konﬂiktparteien werden auch als Konﬂiktverursacher wahrgenommen. Damit werden wir

der Komplexität der Konﬂikte nicht gerecht. Meistens sind die Konﬂiktparteien Symptom-

träger, und die Ursachen stehen im Hintergrund.

In Tab. 4.15 sind die wesentlichen Konﬂiktarten aufgeführt, die in der Projektarbeit

immer wieder vorkommen. Diese sind gruppiert nach den grundsätzlichen Eigenheiten der

Projekte (Abschn. 1.2). Die Tabelle zeigt auch, dass sich die Konﬂikte je nach Konﬂiktart

unterschiedlich äußern können (Abschn. 4.4.8.2).

4.4.7.1

Ziel- und Interessenkonflikt

Ein Zielkonﬂikt tritt dann auf, wenn zwei oder mehrere Parteien unterschiedliche Ziele

und Interessen verfolgen (Kreyenberg 2005, S. 27). Die möglichen Zielkonﬂikte in der

Projektarbeit sind vielfältig:

434

Team

Tab. 4.15 Konﬂiktarten im Projekt

Was sind Projekte?

Konﬂiktart

Äußerungsform

Bringen Veränderung

mit sich

– Persönlicher Konﬂikt

– Vorgehenskonﬂikt

– Beziehungskonﬂikt

Abgegrenzte und

einmalige Vorhaben

– Bewertungskonﬂikt

– Verteilungs- und Ressourcenkonﬂikt

Zielgerichtet und

innovativ

– Ziel- und Interessenkonﬂikt

– Rollenkonﬂikt

– Bewertungskonﬂikt

Interdisziplinär

– Wertekonﬂikt

– Rollenkonﬂikt

– Struktureller und organisatorischer Konﬂikt

Projektcharakter

ändert sich

– Vorgehenskonﬂikt

– Bewertungskonﬂikt

Schwierig zu planen

und zu steuern

– Vorgehenskonﬂikt

– Bewertungskonﬂikt

Brauchen außeror-

dentliche Ressourcen

– Verteilungs- und Ressourcenkonﬂikt

– Zielkonﬂikt

– Vorgehenskonﬂikt

Risikoexponiert

– Bewertungskonﬂikt

– Wertekonﬂikt

– Persönlicher Konﬂikt

Projekte sind Organi-

sationen

– Struktureller Konﬂikt

– Latenter oder offener

Konﬂikt

– Heißer oder kalter

Konﬂikt

– Verschobener oder

echter Konﬂikt

Zielkonﬂikte treten in Projekten vielfach dann auf, wenn die Ziele mit den entsprechen-

den Gewichtungen nicht umfassend ausgearbeitet, verhandelt und vom Auftraggeber

nicht abgesegnet wurden.

Im magischen Dreieck stehen die voneinander abhängigen Einﬂussfaktoren „Scope“,

„Kosten“ und „Zeit“ in einer gegenseitigen Spannung, die auch Konﬂikte erzeugen

kann. Jeder Kunde oder Auftraggeber erwartet als Projektresultat so viel Qualität oder

Funktionalität wie möglich. Dies jedoch innerhalb begrenzter Zeit und zu limitierten

Kosten.

Unterschiedliche Interessen und Erwartungen der Stakeholder.

Das agile Projektmanagement ist für Zielkonﬂikte weniger anfällig, da diese Projekte

viel mehr über eine Vision als über speziﬁsche Ziele geführt werden. Voraussetzung ist

allerdings, dass dem Product Owner sämtliche Entscheidungskompetenzen zugesprochen

werden. Sollte das nicht der Fall sein, wird es zwischen dem Product Owner und den

Entscheidungsorganen der Stammorganisation zu Ziel- und Interessenkonﬂikten kommen.

4.4

Konfliktmanagement und Krisen

435

4.4.7.2

Verteilungs- und Ressourcenkonflikt

Jedes Projekt benötigt persönliche, ﬁnanzielle oder technische Ressourcen. Die Parteien

sind sich zwar einig über die Wichtigkeit eines Projektes. Weil die persönlichen, ﬁnanzi-

ellen und technischen Ressourcen aber beschränkt sind, entsteht ein Konﬂikt bezüglich

der Zuteilung der Ressourcen (Kreyenberg 2005, S. 29), ein Verteilungskonﬂikt.

Ob agile oder klassische Projektorganisation, in beiden Ansätzen kommt es zu Vertei-

lungskonﬂikten, wenn . . .

die Aufwandschätzungen nicht realistisch sind oder zu wenig Budget freigegeben wur-

de;

die Aufwandschätzungen während des Projektverlaufs nicht aktualisiert werden;

die Projekte über eine Koordination in die Stammorganisation eingebunden sind und

die Linienvorgesetzten immer wieder an den Prioritäten Veränderungen vornehmen;

die Projekte nicht in einer Multiprojektplanung konsolidiert werden;

auf der strategischen Ebene kein Projektportfolio besteht, über welches die Geschäfts-

leitung die Prioritäten transparent setzen und steuern kann.

Gut geschützt vor diesen Konﬂikten sind oft nur die strategisch wichtigen Projekte. Bei

allen anderen Projekten ist der Kampf um die Ressourcen eine wiederkehrende Heraus-

forderung für Projektleiter und Scrum Master.

4.4.7.3

Struktureller und organisatorischer Konflikt

Eine weitere wesentliche Konﬂiktquelle liegt in der Integration der Projektorganisation in

die Stammorganisation. Projekte sind immer temporäre Organisationsformen, welche auf

eine speziﬁsche Art in die permanente Linienorganisation integriert sind. Vor allem die

Integrationsformen der Projektkoordination sowie der Matrix sind konﬂiktanfällig. In

der Projektkoordination ist der Projektleiter ein Vermittler und Entscheidungsvorbereiter

und stark von den Entscheidungen der Linienvorgesetzten abhängig. In der Matrix-Orga-

nisation hat der Projektleiter fachliche Weisungsbefugnis gegenüber seinen Mitarbeitern,

aber die Konsequenz daraus ist, dass alle Mitarbeiter zwei Vorgesetzte haben, welche sich

oftmals in ihren Prioritäten nicht gut abstimmen.

Wenn es sich dann noch um ein Kundenprojekt handelt und ein Kundenvertreter in die

Projektorganisation integriert ist oder sogar als deren formaler Auftraggeber agiert, ist ein

struktureller Konﬂikt fast garantiert.

Strukturelle und organisatorische Konﬂikte treten auf, wenn . . .

nicht explizit geklärt und besprochen ist, wie ein Projekt in die Stammorganisation

eingebunden wird und darauf basierend die Entscheidungskompetenzen und der Füh-

rungsstil (z. B. laterale Führung) nicht abgestimmt sind;

Projektrollen und -gremien zwar deﬁniert sind, diese ihre Aufgabe nicht wahrnehmen

(z. B., wenn der Auftraggeber im Projekt nicht sichtbar ist);

in Kundenprojekten die Zuständigkeiten und Informationsﬂüsse zwischen der internen

und der Kundenorganisation nicht abgestimmt sind.

436

Team

Agile Projektteams sind mit dem Konzept der Selbststeuerung gut geschützt gegen Ein-

griffe aus der Stammorganisation. Natürlich können innerhalb des Teams immer wieder

Konﬂikte auftreten, weil jedes Teammitglied situativ sowohl Aufgaben in Bezug auf die

produktive Arbeit (Arbeit im System) als auch in Bezug auf die Arbeit am System zu über-

nehmen hat. Sollte diese persönliche Bereitschaft oder Flexibilität für die Grundlage der

Selbststeuerung nicht vorhanden sein, oder sollten dem Team vom Product Owner oder

von der Stammorganisation Lösungen vorgegeben werden, sind strukturelle oder organi-

satorische Konﬂikte vorprogrammiert.

4.4.7.4

Bewertungskonflikt

Bewertungskonﬂikte gehen oft auf die unterschiedlichen Vorerfahrungen, Wissensstän-

de und auch Informationsstände der Beteiligten zurück. In diesem Falle sind sich die

Parteien zwar darüber einig, welche Ziele verfolgt werden. Aber es bestehen unterschied-

liche Überzeugungen, auf welchen Wegen und mit welchen Methoden diese Ziele erreicht

werden. Die Effektivität und die Auswirkung der Vorgehensweisen werden unterschied-

lich bewertet (Kreyenberg 2005, S. 27 f.) Agil oder klassisch? Oder doch hybrid, und in

welcher Form? Wie sieht der Meilensteinplan aus? Welches können verbindliche Meilen-

steine sein während der Projektabwicklung?

Auch das Potenzial für Bewertungskonﬂikte ist in klassischen Projekten groß: Projekt-

arbeit ist keine repetitive Arbeit wie die meiste Linienarbeit. Jedes Projekt ist in irgendei-

nem Sinne einmalig. Von dem her wird es auch immer unterschiedliche Überzeugungen

geben, mit welchen Methoden und auf welchen Wegen diese Ziele zu erreichen sind.

Bewertungskonﬂikte treten auf, wenn . . .

der Projektauftrag nicht klar formuliert und auch ausgehandelt wurde;

die Zielsetzungen des Projektes nicht SMART oder ungenau deﬁniert sind;

keine transparenten Kriterien für die Entscheidungsﬁndung festgelegt wurden;

zwischen Projektausschuss und Auftraggeber die Entscheidungskompetenzen und Ent-

scheidungsmodelle nicht geregelt sind.

Im agilen Ansatz hat der Product Owner die alleinige Entscheidungskompetenz, Sprint-

Resultate abzunehmen. Was er zurückweist, muss nochmals bearbeitet werden.

Die Teams selber sind in dieser Konﬂiktart gefordert, wenn . . .

unterschiedliche Überzeugungen bestehen zu den Anforderungen, die innerhalb eines

Sprints umgesetzt werden;

abweichend wahrgenommen wird, wer wie viel zur Teamleistung beiträgt;

die Arbeit im System einen höheren Wert hat als die Arbeit am System;

der Scrum Master im Falle von Diskrepanzen nicht genügend schnell interveniert.

4.4.7.5

Rollenkonflikt

In Abschn. 2.3.9 sind die unterschiedlichen Rollen in der agilen und klassischen Projekt-

organisation erläutert. In Abschn. 4.1.9 wird die Unterscheidung zwischen Position und

4.4

Konfliktmanagement und Krisen

437

Rolle ausgeführt. Projektarbeit ist für einen Rollenkonﬂikt grundsätzlich stark exponiert,

weil die meisten Projektbeteiligten – außer in der reinen Projektorganisation – mehrere

Rollen gleichzeitig ausfüllen. Je weniger klar diese Rollen deﬁniert und die Rollenüber-

nahmen gestaltet sind, desto größer ist das Konﬂiktpotenzial.

Der klassische Ansatz leidet häuﬁg unter Rollenkonﬂikten. Im Gegensatz zum agilen

Projektmanagement sind hier die Zuständigkeiten zwischen Team, Teilprojektleiter, Pro-

jektleiter sowie Auftraggeber und Projektausschuss oft weniger scharf abgegrenzt.

Der Faktor Mensch ist in beiden Ansätzen gleichbedeutend. Damit sind Rollenkonﬂikte

immer möglich.

Rollenkonﬂikte treten im klassischen Projektmanagement auf, wenn . . .

die Zuständigkeiten der Rollen und Gremien nicht klar deﬁniert sind;

die speziﬁschen Verantwortlichkeiten und Entscheidungskompetenzen nicht über eine

RACI-Matrix oder ein Funktionendiagramm transparent gemacht werden;

der Führungsstil des Projektleiters nicht abgestimmt ist auf die Integration des Projek-

tes in die Stammorganisation (z. B. laterale Führung);

das Kongruenzprinzip A-K-V auf allen Projektebenen nicht einigermaßen ausbalan-

ciert ist;

der Teamentwicklungsprozess (Abschn. 4.2) aus dem Storming nicht in ein konstruk-

tives Norming geführt wird.

Im agilen Ansatz sind Rollenkonﬂikte wahrscheinlich, wenn . . .

dem Product Owner nicht sämtliche Entscheidungskompetenzen zugesprochen wer-

den;

der Scrum Master aktiv im Team mitarbeitet;

dem Team die Entscheidungskompetenzen im Bereich der Anforderungen oder der

Selbstorganisation nicht zugestanden werden;

das Team zu wenig ausgeglichen ist und wenige Leistungsträger die Gesamtperfor-

mance des Teams stemmen müssen.

4.4.7.6

Persönlicher Konflikt

Bei persönlichen Konﬂikten (auch seelische Konﬂikte genannt) verspüren die Menschen

in sich unterschiedliche Entscheidungs- oder Verhaltenstendenzen (Kreyenberg 2005,

S. 30). Persönliche Konﬂikte der Projektbeteiligten sind umso stärker, je widersprüch-

licher beziehungsweise je unklarer die Vorgaben für das Projekt sind. Diese inneren

Entscheidungskonﬂikte können danach unterteilt werden, welche Möglichkeiten einer

Person realistisch zur Verfügung stehen. Abb. 4.22 fasst die drei – vom Psychologen Kurt

Lewin entwickelten – Konﬂikte zusammen.

Annäherungs-Annäherungskonﬂikt

Einer Person stehen zwei Optionen offen. Beide sind attraktiv. Die Person hat ein Dilem-

ma: Sie fühlt sich zu beiden hingezogen. Es ist aber unmöglich, beide Ziele gleichzeitig

438

Team

Vermeidungs-Vermeidungs-Konﬂikt

Die Person muss zwischen zwei Gege-

benheiten entscheiden, die sie beide als

Übel ansieht.

Annäherungs-Vermeidungs-Konﬂikt

Die Person steht vor der Entscheidung,

die ihr sowohl Wertvolles wie Übles

bringt.

Annäherungs-Annäherungs-Konﬂikt

Die Person steht zwischen zwei Zielen,

die sie für gleich wertvoll hält, aber nicht

gleichzeitig anstreben/erreichen kann.

Abb. 4.22 Seelische Konﬂikte. (Nach Berkel 2014, S. 15 f.)

zu realisieren. Der Konﬂikt besteht darin, dass ein Entscheid gefällt werden muss für eine

der beiden Optionen. Die andere Möglichkeit scheidet aus.

Der Scrum Master nimmt Spannungen im Team wahr. Er muss entscheiden,

ob er direkt intervenieren soll, oder ob er es riskieren soll, dass das Team die

Probleme selber bewältigt und damit weiter zusammenwächst.

Der Projektleiter muss sich entscheiden, ob er eine Teamleitung in der Linie

übernehmen oder ob er weiter Projekte leiten möchte.

Vermeidungs-Vermeidungs-Konﬂikt

Im Fall des Vermeidungs-Vermeidungskonﬂikts ist eine Wahl zu treffen zwischen zwei

Möglichkeiten, die beide negative Konsequenzen haben werden. Der Entscheid muss zu-

gunsten des kleineren Übels gefällt werden.

Ein bewährter Projektleiter ist mit seinem Kundenprojekt einen Monat im Ver-

zug. Der Auftraggeber hat die Wahl, ihn hart anzugehen (was er scheut), zusätz-

liche Ressourcen für dieses Projekt bereitzustellen (die er wiederum anderswo

kompensieren muss) oder dann den Kunden zu informieren, dass es einen Ver-

zuggebenwirdinderProjektabwicklung.WasimmerderAuftraggebertunwird,

es wird zu Schwierigkeiten führen.

4.4

Konfliktmanagement und Krisen

439

Annäherungs-Vermeidungs-Konﬂikt

Annäherungs-Vermeidungs-Konﬂikte sind durch Ambivalenz geprägt: Jede Wahlmöglich-

keit hat sowohl positive als auch negative Folgen.

Jemand wird für die Rolle des Product Owners in einem strategischen Entwick-

lungsprojekt nominiert. Er würde damit in eine höhere Einkommensklasse kom-

men und hätte auch endlich mehr Gestaltungs- und Entscheidungskompeten-

zen. Er wäre aber verpflichtet, innerhalb eines Jahres die IPMA Zertifizierung zu

bestehen. Er zweifelt, ob diese anspruchsvolle Aufgabe des Product Owners,

verbunden mit der Zertifizierung, vereinbar ist mit seiner Rolle als junger Fami-

lienvater.

4.4.7.7

Beziehungskonflikt (Sozialer Konflikt)

Beziehungskonﬂikte liegen dann vor, wenn es in der Beziehung zwischen Menschen zu

unterschwelligen oder offenen Störungen kommt. Dadurch, dass in Beziehungskonﬂikte

zwei oder mehrere Menschen involviert sind, haben diese eine ganz andere Dynamik als

die persönlichen Konﬂikte (Berkel 2014, S. 18 ff.).

Zweier- oder Paarkonﬂikte

Paarkonﬂikte erleben wir nicht nur in unseren privaten Beziehungen. Sehr oft erfahren

wir auch im Arbeitskontext konﬂiktbeladene Situationen zwischen zwei Personen: Vor-

gesetzte, Mitarbeiter, Verhandlungspartner usw. Mögliche Ursachen für Zweierkonﬂikte

sind:

Nähe vs. Distanz: Das Bedürfnis nach Nähe und Distanz verändert sich beim Men-

schen immer wieder. Zu viel Abstand oder auch zu viel Nähe erhöht die Spannung

beim Gegenüber. Dieses fühlt sich entweder verlassen oder eingeengt.

Beispiel: Wird ein Arbeitskollege zum Projektleiter ernannt, verändert sich das Nähe-

Distanz-Verhältnis. Die beförderte Person wird eher auf Distanz gehen, um ihrer neuen

Führungsrolle gerecht zu werden. Die ehemalige Kollegin erwartet jedoch immer noch

die gleiche Nähe wie vor der Beförderung.

Bewahren vs. Verändern: Jeder Mensch hat seine eigene Entwicklungsdynamik: Der

eine ist sehr offen für Veränderung, neugierig und permanent auf der Suche nach neuen

Möglichkeiten. Der andere sucht mehr Stabilität in seinem Leben, möchte das Erreichte

bewahren und ﬁndet Halt und Zufriedenheit in wiederkehrenden Ritualen und Abläu-

fen.

Kommt z. B. eine Kollegin voller Enthusiasmus aus einer Schulung zurück in die Fir-

ma, möchte sie das Gelernte sofort zur Anwendung bringen und bestehende Abläufe

verändern. Dies wird zu Konﬂikten führen mit den Personen, die das Bestehende be-

wahren wollen.

Kommunikation: Zwischenmenschliche verbale wie auch nonverbale Kommunikation

haben viel Konﬂiktpotenzial (Abschn. 3.9).

440

Team

Dreier- oder Dreieckskonﬂikte

Mit einer dritten Partei treten neue Phänomene in Konﬂikten auf, die in einer Zweierbe-

ziehung nicht möglich sind:

Koalition: Zwei Personen verbünden sich gegen einen Dritten.

Rivalität: Ein Vorgesetzter spielt zwei seiner Mitarbeiter gegeneinander aus. Diese

konkurrieren nun, um die Gunst des Chefs zu gewinnen.

Beziehung: Bei einem Paar bestimmen die Persönlichkeiten die Beziehung. Die Per-

sönlichkeit ist dann der wesentliche Einﬂussfaktor auf den Konﬂikt. In einem Drei-

erkonﬂikt ist es genau umgekehrt: Die Persönlichkeit der involvierten Personen steht

nicht im Vordergrund, sondern die Beziehung, die die Konﬂiktparteien zueinander ha-

ben: So hat der Vorgesetzte zu seinen beiden Mitarbeitern je eine eigene Beziehung.

Gruppenkonﬂikte

In der Gruppe kommen weitere Konﬂiktpotenziale zum Vorschein:

Revier: Jede Gruppe betrachtet ein Territorium als ihr Zuhause und verteidigt dieses

gegen Eindringlinge. Der Mensch in der Gruppe ist nicht nur sensibel, wenn räumliche

Grenzen missachtet werden. Die gilt auch für das Überschreiten von Zuständigkeiten

und Kompetenzen.

Rangordnung: Jede Gruppe bildet bewusst oder unbewusst eine Rangordnung. Be-

kannt ist die Rangordnung nach:

– Anführer (Alpha)

– Experte (Beta)

– Einfaches Gruppenmitglied (Gamma)

– Außenseiter (Omega)

Solange eine Gruppe die Rangordnung nicht festlegt, ist sie nicht arbeitsfähig. Neue

Organisationseinheiten oder auch Projekte lösen unweigerlich Rangordnungskämpfe

aus. Nach Berkel ist eine Gruppe nicht erfolgreich wegen des formalen Organigramms,

sondern weil die interne Rangordnung den funktionalen Anforderungen am besten ent-

spricht. Wird die Organisation nicht als zielführend angesehen oder nicht akzeptiert,

führt dies permanent zu Friktionen. Wiederkehrende Konﬂikte sind häuﬁg ein Hinweis

für eine nicht akzeptierte Organisation.

Führung: Jede Gruppe, sei es ein Projektteam oder eine Linienorganisation, muss zwei

grundlegende Anforderungen erfüllen: Sie muss ihre Ziele erreichen und einen mini-

malen Zusammenhalt sicherstellen können. Außer in der reinen Projektorganisation hat

jede Person in der Projektarbeit zwei oder mehrere Vorgesetzte: den Linienvorgesetzten

und den Projektleiter. Die Art und Weise der Führung sowie die möglichen Diskrepan-

zen und Friktionen der Führungsverantwortlichen untereinander beinhalten weiteres

Konﬂiktpotenzial.

4.4

Konfliktmanagement und Krisen

441

4.4.7.8

Wertekonflikt

Werte bilden den Kern der Identität von sozialen Systemen, seien dies Einzelpersonen,

Gruppen oder ganze Organisationen. Werte symbolisieren das, was wir für wichtig und

richtig halten und an was wir uns gebunden fühlen. Werte geraten untereinander nicht in

einen Konﬂikt; es sind immer die Menschen, die sich mit speziﬁschen Werten identiﬁ-

zieren. Wer befürchtet, dass die eigenen Werte infrage gestellt werden, fühlt sich persön-

lich in der Identität angegriffen. Deshalb wird oft so heftig auf Konﬂikte auf dieser Ebene

reagiert (Berkel 2014, S. 93).

Dabei kann es sich um persönliche Werte wie auch um Werte in einer Organisationskul-

tur handeln. Werte stehen in einem dynamischen Bezug zueinander: In der Erwerbsarbeit

liegt die Spannung hauptsächlich zwischen den Werten

Leistung (Organisation) und

Zufriedenheit (Individuum).

Je stärker die Firmenleitung auf Leistung setzt, desto stärker treten die Werte der in-

dividuellen Zufriedenheit wie Wohlbeﬁnden oder Gesundheit in den Hintergrund (Berkel

2014, S. 23).

Die interdisziplinäre und oft auch interkulturelle Projektarbeit ist exponiert für Werte-

konﬂikte. Diese kommen im agilen wie im klassischen Ansatz gleichermaßen vor.

Auf der individuellen Ebene können Unterschiede auftreten in den Erwartungen an die

Art und Weise, wie die Prioritäten gesetzt werden, die Kommunikationskultur gestaltet

oder auch die Entscheide gefällt werden.

Auf der organisationalen Ebene treten Unterschiede meistens zwischen den Teilsys-

temen wie Verkauf, Produktion und Entwicklung auf. Diese verfolgen unterschiedliche

und auch gegensätzliche Werte in deren Aufgaben: Der Verkauf setzt auf Kundennähe,

Flexibilität und kompetitive Preise, die Produktion will Efﬁzienz in den Prozessen und

tiefe Lagerstände, und in der Entwicklung stehen Innovation und hohe Qualität im Vor-

dergrund.

4.4.8

Konfliktdiagnose

Mit den Konﬂikten ist es wie mit einem Arztbesuch: Ist die Diagnose falsch, wird auch

die Behandlung nicht zielführend sein. Durch die Konﬂiktdiagnose soll eine unreﬂektierte

Personiﬁzierung von Konﬂikten oder auch vorschnelle Schuldzuweisung vermieden wer-

den. Nur wenn wir verstanden haben, welche Ursachen hinter den Konﬂiktsymptomen

stecken, können wir Konﬂikte zielführend bearbeiten.

4.4.8.1

Hypothesen bilden statt wissen wollen

Der Mensch ist ein nicht-triviales System (Abschn. 1.6.2). Deshalb können wir nie wissen,

was er empﬁndet, wie er denkt oder wie er handelt. Das Einzige, was wir tun können in

442

Team

Bezug auf andere Menschen oder Gruppen, ist, Annahmen – und damit Hypothesen – zu

bilden.

Ob jedoch eine Hypothese richtig oder falsch ist, darüber bestimmt immer die entspre-

chende Partei, für welche diese gebildet wurde. Die Hypothese wird nur dann zu einem

Faktum, wenn sie von den involvierten Parteien bestätigt worden ist.

4.4.8.2

Äußerungsform von Konflikten

In den oben ausgeführten Konﬂiktarten kommt der Konﬂiktgegenstand zum Ausdruck.

Losgelöst davon kann die Art und Weise, wie der Konﬂikt zum Ausdruck kommt, ganz

unterschiedlich sein (Lippmann 2008, S. 327 ff.)

Latenter und offener Konﬂikt

Bei einem latenten Konﬂikt liegen zwar Gegensätze zwischen Parteien vor, diese haben

bis zum Moment allerdings noch nicht zu feindseligen Handlungen geführt. Das wäre

bei einem offenen Konﬂikt der Fall. Für einen Projektleiter oder Scrum Master kann es

wertvoll sein, schon latente Konﬂikte zu erkennen, um in einem frühen Stadium auf diese

eingehen zu können und sie damit auch nicht eskalieren zu lassen.

Der Projektleiter kann z. B. mit einem seiner Teilprojektleiter wesentliche Diffe-

renzen haben. Weil der Projektleiter aber weiß, dass der Teilprojektleiter einen

engen Bezug zum Auftraggeber hat, wird er den Konflikt nicht eskalieren lassen.

Sollte der Auftraggeber das Projekt aber an einen Kollegen abgeben, würde der

Konflikt ausbrechen.

Heißer und kalter Konﬂikt

In heißen Konﬂikten verläuft das Zusammenspiel sehr aktiv, die Parteien reagieren eher

überempﬁndlich. Angriff und Verteidigung sind für alle spür- und erkennbar. Sie werden

impulsiv und emotional geführt. Die Energie der Parteien wird genährt von den über-

zeichneten positiven Selbstbildern.

In kalten Konﬂikten ist das Zusammenspiel gelähmt. Enttäuschung, Frustration und

Hassgefühle werden unterdrückt und wirken in den Parteien destruktiv weiter. Eine Aus-

einandersetzung ﬁndet nicht oder nur indirekt statt, da sich die Parteien gegenseitig aus-

weichen und einen direkten Kontakt vermeiden.

Zwischen dem heißen und kalten Konﬂikt sind auch Wechselwirkungen möglich: So

kann ein kalter Konﬂikt nach Monaten oder Jahren plötzlich als heißer Konﬂikt eskalieren.

Aber auch das Gegenteil ist möglich: Wird ein heißer Konﬂikt nicht bewältigt, können sich

die Konﬂiktparteien in einen kalten Konﬂikt zurückziehen (Glasl 2004; siehe Abb. 4.23).

In Sitzungen kann gut beobachtet werden, ob eine heiße oder eine kalte Kon-

fliktkultur besteht. Wird offen debattiert und argumentiert? Steht jemand für

seine Überzeugung ein, auch wenn diese nicht von der Mehrheit geteilt wird?

4.4

Konfliktmanagement und Krisen

443

► Glaube an konstruktive Ziele verloren

► Frustration, Sarkasmus

► Verantwortung für Tun wird nicht

übernommen

► Rückzug, ausweichen, vermeiden

Erhitzen für eigene Ziele ◄

Übermotivation ◄

über jeden Zweifel erhaben ◄

Kritik zurückweisen ◄

Angriff, Konfrontation ◄

• dynamisch

• aussenorientiert

• spontan

• provokativ

• direkte Kommunikation

• risikofreudig

• zukunftsorientiert

• statisch

• innenorientiert

• nach Regeln

• reaktiv

• indirekte Kommunikation

• Risiko vermeiden

• vergangenheitsorientiert

versus

formell

informell

kalt

heiss

Abb. 4.23 Heiße und kalte Konﬂikte. (Basierend auf Schwarz 2014)

Das könnte einen heißen Konflikt auslösen. Gehen sich die Sitzungsteilneh-

mer jedoch aus dem Weg und versuchen, die andere Partei „hinten herum“

schlechtzumachen und zu diffamieren, wäre dies ein kalter Konflikt.

Verschobener Konﬂikt (Ersatzbefriedigungen)

Eine weitere Differenzierung in der Äußerungsform besteht darin zu untersuchen, ob zwi-

schen den Parteien überhaupt die eigentliche Streitfrage ausgetragen wird. Möglich ist

auch, dass die im Zentrum stehende Differenz nur vom eigentlichen Thema ablenken soll.

Wenn das Gehirn ﬁndet, dass es nicht bekommt, was es braucht, versucht es, sich zu

nehmen, was es bekommen kann (Ballreich und Hüther 2009). Das sind dann Ersatzbe-

friedigungen.

Ein Projektleiter fordert von seinen Mitarbeitern immer wieder schnellstmöglich

Leistungen ein, obwohl diese im Vergleich zu anderen offenen Punkten eine tie-

fe Dringlichkeit haben.Die Wahrscheinlichkeit ist hoch,dassesdem Projektleiter

gar nicht um die effektiven Tätigkeiten geht: Er will immer wieder neu seinen

Status und seine Einflussnahme spüren.

444

Team

Vordergründig ist das eine gute Strategie, weil dadurch wenigstens das Gehirn Ruhe

gibt. Die eigentliche Sehnsucht oder das Grundbedürfnis dahinter wird jedoch nicht ge-

stillt. Möglicherweise entstehen auch Konﬂikte über ein Thema oder ein Anliegen, das

aus der subjektiven Perspektive für sehr wichtig gehalten wird. In Tat und Wahrheit steckt

dahinter ein anderes Bedürfnis.

Ein verschobener Konﬂikt kann daran erkannt werden, dass . . .

die Auseinandersetzung keinen zwingenden Grund hat und als „gesucht“ erscheint;

der Streitgegenstand in keinem Verhältnis zur Konﬂiktstärke steht;

kein wahres Interesse erkennbar ist;

naheliegende Lösungen vermieden werden;

der Konﬂikt zäh und kleinlich ausgetragen wird.

Verschobene Konﬂikte können eigentlich nur nachhaltig gelöst werden, wenn der zu-

grunde liegende echte Konﬂikt angegangen wird.

4.4.8.3

Konfliktstile

Die Abb. 4.24 stellt die unterschiedlichen Stile dar, die Menschen in Konﬂikten anwenden.

Diese werden unterschieden in Bezug auf die Selbstbehauptung respektive die Rücksicht-

nahme der entsprechenden Konﬂiktparteien (Berkel 2014, S. 60 ff.).

Die Evolution hat dem Menschen drei Konﬂiktstile mitgegeben, welche er mit allen

Tierarten teilt. Die Ausführungen zum Verlust der Selbststeuerung mit den Notprogram-

men des Gehirns (Abschn. 4.4.6.2) erklären die drei reﬂexgesteuerten Konﬂiktverhalten.

Absolute Selbstbehauptung: Angriff

Ich will mich durchsetzen und die Gegenpartei soll verlieren (Win/Lose). Offene Kon-

frontation (heißer Konﬂikt) oder indirekter Widerstand (kalter Konﬂikt).

Absolute Rücksichtnahme: Flucht

Die Gegenpartei setzt sich durch, ich ordne mich unter und gehorche (Lose/Win).

Dem starken Wunsch nach Harmonie und Zusammenhalt Vorfahrt gewähren.

Weder-noch: Totstellen

Beide Parteien versuchen, der Auseinandersetzung aus dem Weg zu gehen. Beide verlieren

(Lose/Lose). Der Konﬂikt wird geleugnet oder als irrelevant heruntergespielt. Möglich ist

auch, dass der Kontakt abgebrochen wird oder dass sich die Parteien mit dem aktuellen

Zustand begnügen.

Solange die Intensität des Konﬂiktes für die Betroffenen nicht zu stark ist, können

sie über ihre antrainierten Verhaltensmuster aus der Kindheit verfügen. Im besten Fall

entwickeln sie über ihre kognitiven Fähigkeiten Konﬂiktstile, die nur dem Menschen mit

seiner Vernunft möglich sind.

4.4

Konfliktmanagement und Krisen

445

hoch – altruistisch

hoch – egoistisch

gering

Flucht (Lose/Win)

• Forderung der Gegenseite

• Sich unterordnen,

gehorchen

• Starker Wunsch nach

Harmonie

Integrieren (Win/Win)

• Ressourcen erweitern

• Bedürfnisse klären

• Neue Optionen

erschliessen

Aushandeln (Kompromiss)

Wechselseitig Konzessionen machen

Streitpunkte differenzieren

Totstellen (Lose/Lose)

• Gespräch aus dem Weg

gehen

• Konﬂikt leugnen

• Um das Thema

herumreden

Angriff (Win/Lose)

• Offen (direkt)

konfrontieren, attackieren

• Verdeckt (indirekt)

Prozesskontrolle,

Widerstand

Orientierung an den Zielen und Belangen der Gegenpartei

(Rücksichtnahme)

Orientierung an meinen Zielen und Belangen

(Selbstbehauptung)

Abb. 4.24 Typologie der Konﬂiktstile. (Berkel 2014, S. 60)

Kompromiss

Die Streitpunkte können differenziert werden. Beide Parteien weichen von der Maximal-

forderung ab. Man räumt sich gegenseitig Konzessionen ein.

Integration

Die wahren Ursachen des Konﬂiktes können identiﬁziert werden. Es ist möglich, den

Konﬂikt in einer Form zu bewältigen, welche für alle involvierten Parteien einen Gewinn

darstellt (Win/Win).

Auf den speziﬁschen Konﬂiktstil der Integration wird im Harvard-Konzept in Abschn.

4.4.10.4 ausführlich eingegangen.

Effektivität der Konﬂiktstile

Die schlechte Nachricht: Den zielführendsten Konﬂiktstil gibt es nicht. Je nach Kon-

ﬂiktart, Dauer, Intensität und den involvierten Personen ist ein anderer Stil erforderlich.

Immerhin können die Effektivität und Angemessenheit der Konﬂiktstile eingeschätzt wer-

den (Abb. 4.25). Effektivität: Können die Ziele erreicht werden – die eigenen und/oder

fremde? Angemessenheit: Kann vermieden werden, die Beziehungen oder die gültigen

Regeln zu verletzen?

446

Team

gross

klein

angemessen

unangemessen

Effektivität

Verhalten

Kämpfen

(Win/Lose)

Vermeiden

(Lose/Lose)

Integrieren

(Win/Win)

Aushandeln

(Kompromiss)

Nachgeben

(Lose/Win)

Abb. 4.25 Effektivität der Konﬂiktstile. (Berkel 2014, S. 62)

Die Darstellung macht deutlich, dass das Ziel jeder Konﬂiktbearbeitung immer in der

Integration oder in der Kooperation (im Aushandeln) liegt. Diese beiden Konﬂiktstile sind

kognitiv geprägt. Nachgeben, Vermeiden und Kämpfen hingegen sind vom Affekt geprägt.

Konﬂiktsituationen sind für den Menschen immer auch Stresssituationen. Oder sie wer-

den es mit zunehmender Intensität und Dauer. Konﬂiktstile können sich auch über die Zeit

verändern: Was einmal mit einer offenen Haltung der Integration oder des Kompromis-

ses begonnen wurde, kann bei zunehmendem Stress oder und durch das Hervortreten der

Grundemotionen Angst und Ärger zu den affekthaften Stilen des Kampfes, der Vermei-

dung oder des Nachgebens führen.

Hinter den Konﬂiktstilen Kämpfen, Vermeiden und Nachgeben verbergen sich oft

Ängste:

Kämpfen: Ich will nicht unsicher oder als Schwächling wahrgenommen werden.

Totstellen: Ich habe Angst davor, eine konkrete Position einzunehmen und damit auch

in die Verantwortung gezogen zu werden.

Flucht: Ich habe Angst, dass ein Einsatz für meine Bedürfnisse als aggressiv, gefühllos

oder kalt wahrgenommen werden könnte.

4.4

Konfliktmanagement und Krisen

447

Verhärtung

Debatte

Taten

Koalition

Gesichtsverlust

Drohstrategie

Begrenzte Vernichtungsschläge

Zersplitterung

Gemeinsam in den Abgrund

Hauptphasen

Kooperation

und Konkurrenz

Sich selbst

erfüllende

Prophezeiung

Entwürdigung/

Verdinglichung

Abb. 4.26 Eskalationsstufen und deren Hauptphasen. (Glasl 2004, S. 218 f.)

4.4.9

Modelle zur Konfliktdiagnose

4.4.9.1

Konflikt-Eskalationsstufen

Das Modell der Konﬂikt-Eskalationsstufen von Friedrich Glasl (Abb. 4.26) hilft, die In-

tensität eines Konﬂiktes zu erkennen. Das Phänomen dahinter ist, dass ungelöste Konﬂikte

über die Zeit zunehmend die destruktiven Kräfte des Menschen aktivieren. Das Verhalten

der Konﬂiktparteien wird dabei immer emotionaler und unberechenbarer. Damit geht

schrittweise die Steuerfähigkeit verloren. Es wird für die Konﬂiktparteien immer schwie-

riger, zwischen der objektiven Wahrheit und der Wahrnehmung zu differenzieren und den

Konﬂikt selbständig und neutral lösen zu können.

Phase I: Kooperation und Konkurrenz (Win/Win)

Während der in Tab. 4.16 dargestellten Phase I steht bei den involvierten Parteien noch

das Wohlergehen aller im Vordergrund. Die involvierten Parteien sind überzeugt davon,

dass alle als Gewinner aus dem Konﬂikt hervorgehen können. Alle haben dem Konﬂikt

gegenüber eine konstruktive Haltung. Der Konﬂiktstil der Integration (Win/Win) steht im

Vordergrund.

448

Team

Tab. 4.16 Phase I: Kooperation und Konkurrenz (Win/Win)

Stufe

Wie kann die Eskalationsstufe erkannt werden?

Verhärtung

– Standpunkte kristallisieren sich heraus, verhärten sich und prallen aufein-

ander.

– Die Wahrnehmung von Spannungen führt zu Verkrampfungen. Trotzdem

besteht die Überzeugung, dass die Spannungen durch Gespräche lösbar

sind.

– Keine starren Parteien oder Lager.

Debatte

– Polarisation im Denken, Fühlen und Wollen.

– Sichtweise von Überlegenheit und Unterlegenheit.

– Argumente werden benutzt, um die Gegenpartei im Gefühlsleben zu

treffen.

Taten

– Die Überzeugung, dass „Reden nicht mehr hilft“, gewinnt an Bedeutung.

– Strategie der vollendeten Tatsachen.

– Die Empathie für den „anderen“ geht verloren. Fehlinterpretationen neh-

men zu, da das nonverbale Verhalten dem verbalen nicht mehr entspricht.

Tab. 4.17 Phase II: Selbsterfüllende Prophezeiung (Win/Lose)

Stufe

Wie kann die Eskalationsstufe erkannt werden?

Koalitionen

(„Seilschaften“)

– Die Parteien manövrieren sich gegenseitig in negative Rollen und

bekämpfen sich.

– Es wird versucht, die eigenen Vorurteile zu bestätigen.

– Anhänger für die eigene Partei werden geworben.

Gesichtsverlust

– Es kommt zu öffentlichen und direkten (verbotenen) Angriffen, die

auf den Gesichtsverlust des Gegners abzielen.

– Gegenpartei wird als Personiﬁzierung des Bösen gesehen.

Drohstrategie

– Drohungen und Gegendrohungen nehmen zu.

– Der Druck wird erhöht, damit nimmt der Stress zu.

– Die Beteiligten kommen nicht mehr zum Überlegen, was sie tun.

Phase II: Selbsterfüllende Prophezeiung (Win/Lose)

Der Glaube an eine konstruktive Konﬂiktlösung ist bei den involvierten Parteien nicht

mehr vorhanden. Der Fokus liegt nun auf der Differenz und auf dem eigenen Gewinn. Die

Selbstbehauptung steht im Vordergrund (Win/Lose). Tab. 4.17 beschreibt die drei Stufen

der Phase II.

Phase III: Entwürdigung, Verdinglichung (Lose/Lose)

Der Konﬂikt ist in Phase III so weit eskaliert, dass den Parteien klar wird, dass nie-

mand mehr gewinnen kann (Lose/Lose). Beide Parteien sind nun noch bemüht, weniger

Schaden davonzutragen als die andere. Die Beziehungen zwischen den Konﬂiktpartei-

en werden nun völlig funktionalisiert. Man behandelt sich gegenseitig als Objekt, ohne

menschliche Regung und Anteilnahme. Tab. 4.18 zeigt die drei letzten Stufen zur gegen-

seitigen Vernichtung.

4.4

Konfliktmanagement und Krisen

449

Tab. 4.18 Phase III: Entwürdigung, Verdinglichung (Lose/Lose)

Stufe

Wie kann die Eskalationsstufe erkannt werden?

Begrenzte Vernich-

tungsschläge

– Der Gegner wird nicht mehr als Mensch gesehen.

– Begrenzte Vernichtungsschläge als „passende“ Antwort.

– Das Lügen wird zur Tugend, Hauptsache es schadet dem Gegner.

Zersplitterung

– Die Beziehungen werden systematisch unterbunden.

– Wichtige Funktionen werden lahmgelegt.

– Eine Regeneration der Kräfte ist nicht mehr möglich.

Gemeinsam in den

Abgrund

– Totale Konfrontation.

– Die Vernichtung des Gegners wird zum Preis der Selbstvernich-

tung in Kauf genommen.

Für das Konﬂiktmanagement im Projekt lassen sich aus dem Modell der Eskalations-

stufen folgende Schlüsse ziehen:

1. Je länger man wartet, den Konﬂikt zu bearbeiten, desto schwieriger wird es.

2. Bis zur Stufe 3 ist eine Konﬂiktlösung möglich, aus der alle involvierten Parteien einen

Gewinn ziehen. Bei Konﬂikten, die bis zur Stufe 6 eskalieren, gibt es im besten Fall

noch eine Gewinner-Verlierer-Lösung. Danach verlieren grundsätzlich beide Parteien.

Grenzen der Selbsthilfe

Sobald ein sozialer Konﬂikt die Stufe 3 überschreitet, beginnen die involvierten Perso-

nen in der Stufe 4 (Koalitionen), so viele Anhänger wie möglich für die eigene Partei zu

gewinnen. Über die größere Koalition soll dann die Konﬂiktlösung hergestellt werden.

Wenn sich ab dieser Phase ein Projektleiter, Scrum Master oder Linienvorgesetzter mit

der gut gemeinten Absicht zur Konﬂiktvermittlung einschalten sollte, werden die Parteien

versuchen, diese Person in ihre eigene Koalition hineinzuziehen. Somit verliert er seine

Neutralität und wird selber zur Konﬂiktpartei. Deshalb sollte ab der Eskalationsstufe 4

zwingend ein Moderator oder ein Mediator beigezogen werden. Falls dies eine ﬁrmenin-

terne Person ist, soll sie nicht aus dem gleichen hierarchischen Bereich kommen, sondern

z. B. aus einer Stabsstelle oder von HR. Noch besser übernimmt dies eine ﬁrmenexterne,

unabhängige Person. Die Abb. 4.27 stellt die Grenze der Selbsthilfe dar und fasst auch

Empfehlungen zur Intervention in Konﬂikten zusammen.

4.4.9.2

Schichtenmodell

Wie gehen wir in einer Konﬂiktdiagnose nun vor? Was kann uns Orientierung geben, da-

mit wir nicht in eine vorschnelle Personiﬁzierung des Konﬂiktes fallen und die Symptome

von den Ursachen trennen können? Das Schichtenmodell in Abb. 4.28 liefert uns dazu

wertvolle Unterstützung (Schmidt und Berg 2008, S. 158 ff.)

450

Team

Hauptphasen

► ab hier ist Unterstützung notwendig

Gewinner – Gewinner

Gewinner – Verlierer

Verlierer – Verlierer

Mögliche Rollen

► ab hier ist Unterstützung notwendig

Stufe 1 - 3

Moderation

Stufe 3 - 6

externe Prozessbegleitung Mediation

Stufe 6 - 7

Vermittlung

Stufe 6 - 8

Schiedsverfahren

Stufe 7 - 9

Machteingriff

Sinnvolle Interventionen

► ab hier ist Unterstützung notwendig

Fragen, worum

es geht?

Zuhören

fördern

Einzelgespräche

führen

Selbstbild Eigen-

bild aufarbeiten

Geschichte der

Polarisation

aufarbeiten

Parteien trennen

Gespräche

unterstützen

Verhalten be-

wusst machen

Muster erken-

nen, aufzeigen

Rollenzu-

schreibung

Kritische Vorfälle

analysieren

Alternativen zum Ausstieg anbieten

Innere Antreiber

bewusst

machen

Nonverbales

Verhalten

thematisieren

Gespräche

unterstützen

Un-Werte fest-

halten, Koalition

aufzeigen

Abb. 4.27 Sinnvolle Rollen und Interventionen in Konﬂiktsituationen

Die Konﬂiktbearbeitung nach dem Schichtenmodell fordert zwei Grundsätze:

1. Die Bearbeitung beginnt immer auf der obersten Ebene.

2. Die Konﬂiktbearbeitung soll nur so weit auf die tieferen Ebenen ausgeweitet werden

wie nötig. Es geht nicht darum, jeden Konﬂikt auf die unterste Ebene zu vertiefen.

Das Modell ordnet die Normen und Werte der Organisation und der Person sowie Cha-

raktereigenschaften und Persönlichkeitsproﬁle den zwei untersten Schichten zu. Damit

soll eine vorschnelle Personiﬁzierung des Konﬂiktes verhindert werden. Nach diesem Mo-

dell sind zuerst die Einﬂussfaktoren aus der Arbeitsorganisation, später die Rollenklärung

sowie die Rollenübernahme (Verhalten) zu prüfen.

Zuordnung der Konﬂikttypen zum Schichtenmodell

In einem nächsten Schritt werden in Abb. 4.29 die Konﬂikttypen dem Schichtenmodell

zugeordnet. Das ist natürlich eine Vereinfachung, denn oft hängen die Konﬂikte mit meh-

reren Einﬂussfaktoren (und Schichten) zusammen. Trotzdem macht diese Zuordnung be-

wusst, dass die Ursachen der meisten Konﬂikte der obersten Stufe der Arbeitsorganisation

zugeordnet werden können: Ziel- und Interessenkonﬂikte, Verteilungskonﬂikte, struktu-

4.4

Konfliktmanagement und Krisen

451

Intervention von oben nach unten

1. Arbeitsorganisation (Sachkonﬂikt)

Infrastruktur, Strukturierung der Arbeitszeit

Äussere Arbeitsbedingungen

Anerkennung, Abläufe, Infoﬂuss,Ressourcen (Personen, Finanzen)

2. Rolle

Verteilung von Aufgaben, Verantwortung

und Kompetenzen, Organigramm

Übereinstimmung von Rollen und Fähigkeiten

3. Verhalten

Kommunikations- und Verhaltensmuster

Leitungsstil, Zusammenarbeit, Konﬂiktfähigkeit

4. Normen und Werte

Persönliche Lebenseinstellung

Menschenbilder

Organisationskultur

5. Persönlichkeitsproﬁl

Besonderheiten einer

Person, Identität der

Organisation

Abb. 4.28 Schichtenmodell

relle und organisatorische Konﬂikte sowie Bewertungskonﬂikte. Diese Konﬂikttypen kön-

nen als Sachkonﬂikte subsumiert werden. Auf der nächsttieferen Ebene sind dann die

Rollenkonﬂikte angeordnet.

Die häuﬁgsten Konﬂikttypen sind auf den Ebenen eins und zwei angeordnet. Wenn

die methodischen Ansätze von agil und klassisch sachgemäß in der Projektorganisation

angewendet werden, können viele Konﬂikte vermieden oder aber nach deren Auftreten

bewältigt werden, ohne dass der Mensch eine Rolle spielt. Er ist nur Symptomträger.

Ab Stufe 3 (Verhalten) hat der Mensch als Person Einﬂuss auf den Konﬂikt. Sollten

weder die Arbeitsorganisation noch die Rollen Grund für die Störung sein, wird die Ana-

lyse vertieft auf die Ebene des Verhaltens (Beziehungs- und persönlicher Konﬂikt). Auf

der nächsttieferen Ebene ist der Wertekonﬂikt angeordnet. Vor allem in der interkultu-

rellen Zusammenarbeit können auf dieser Ebene Diskrepanzen auftreten. Dem Persön-

lichkeitsproﬁl wird bewusst keine Konﬂiktart zugeordnet. Im beruﬂichen Kontext sollte

die Identität einer Person so gut wie möglich respektiert und geschützt werden. Es kann

natürlich sein, dass ein Konﬂikt in einem Projekt eine Projektionsﬂäche bildet für eine

Störung auf der Ebene der Persönlichkeit. Selbst in diesem Falle müsste die Störung auf

der Ebene des Verhaltens bearbeitet werden.

452

Team

Intervention von oben nach unten

1. Arbeitsorganisation (Sachkonﬂikt)

Ziel- und Interessenkonﬂikt, Verteilungs- und Ressourcenkonﬂikt,

Struktureller und organisatorischer Konﬂikt, Bewertungskonﬂikt

2. Rolle

Rollenkonﬂikt

3. Verhalten

Beziehungskonﬂikt

Persönlicher Konﬂikt

4. Normen und Werte

Wertekonﬂikt

5. Persönlich-

keitsproﬁl

Abb. 4.29 Zuordnen der Konﬂiktarten zum Schichtenmodell

4.4.9.3

Fragen zur Konfliktdiagnose

Nun sind alle Grundlagen für eine umfassende Konﬂiktdiagnose erörtert. Ob als direkt be-

troffene Partei, als involvierter Vorgesetzter, als Konﬂiktmoderator oder Mediator: Immer

wieder geht es darum, vom Affekt wegzukommen und wieder die kognitiven Fähigkeiten

und damit den Verstand zu aktivieren (Abschn. 4.4.6). Zu diesem Zweck helfen Fragen,

den Konﬂikt in aller Nüchternheit anzuschauen. In Anlehnung an Berkel (2014, S. 45 ff.)

sollen folgende Fragen bearbeitet werden:

1) Die Streitpunkte: Worum geht es?

Was bringen die Parteien gegeneinander vor?

Was verlangen sie voneinander? Was steckt als Anliegen dahinter?

Sehen sie die Streitpunkte gleich? Woher wissen sie das?

Wie erleben die Parteien den Konﬂikt persönlich? Wie wichtig ist er für sie?

Inwieweit sind die Streitpunkte objektiv fundiert oder subjektiv bedingt?

2) Der Verlauf: Wie hat sich der Konﬂikt entwickelt?

Was hat den Konﬂikt ausgelöst?

Welche „kritischen Ergebnisse“ haben ihn verschärft oder abgeschwächt?

4.4

Konfliktmanagement und Krisen

453

Welcher Zustand herrscht jetzt?

Welcher Konﬂikt-Eskalationsstufe nach Glasl kann der Konﬂikt zugeordnet werden?

Wie ist die Äußerungsform des Konﬂiktes: „heiß“ oder „kalt“, latent oder offen, ver-

schoben oder echt?

3) Das Verhalten: Wie agieren die Parteien?

Wie versucht jede Partei, auf die andere einzuwirken?

Manipulieren sie einander? Oder argumentieren sie redlich?

Welche Muster (Reiz-Reaktion) treten immer wieder zwischen ihnen auf?

Welchen Stil setzt jede Partei bevorzugt ein? Bleibt sie starr oder agiert sie beweglich?

Debattieren sie miteinander, reagieren sie aufeinander oder kämpfen sie schon mitein-

ander?

Kann den Konﬂiktparteien ein speziﬁscher Konﬂiktstil zugeordnet werden?

Was bringt den Parteien eine Fortdauer des Konﬂiktes? Was bringt eine Einigung?

Welchen Preis (welche Konzession) sind die Parteien bereit zu bezahlen?

4) Die Parteien: Wer steht im Konﬂikt gegeneinander?

Wer sind die Parteien: Personen? Gruppen? Organisationen? Kollektive?

Bei Personen: Stehen hinter ihnen (Interessen-)Gruppen?

Bei Gruppen: Wer hat das Sagen? Wo und wie greift diese Person in den Konﬂikt ein?

Bei Organisationen: Wie ist die interne Kommunikations-, Macht- und Entscheidungs-

struktur?

Wie sind die Parteien organisatorisch zugeordnet: über-/untergeordnet? gleichrangig?

Wie fühlt sich jede Partei der anderen gegenüber: über-/unterlegen? stark/schwach?

Welches Prinzip sollte in der Beziehung gelten: Gleichheit? Fairness? Bedürftigkeit?

Was kann jede Seite aufgrund ihrer Position verlangen?

5) Erwartungen: Was erhoffen oder befürchten die Parteien von diesem Konﬂikt?

Ist der Konﬂikt für die Parteien unvermeidbar oder vermeidbar? Ist für sie eine Eini-

gung möglich oder unmöglich?

Wer proﬁtiert vom Konﬂikt: Eine Partei? Dritte? Die Organisation?

Wem bringt der Konﬂikt Nachteile: Einer Partei? Dritten? Der Organisation?

Wer zieht Vorteile aus dem andauernden, ungelösten Konﬂikt?

Wie greifen die im System vorhandenen Regelungsmechanismen?

Wie bewerten die Parteien die bisherigen Versuche, den Konﬂikt zu beenden? Was hat

jede unternommen? Mit welchem Effekt?

Hoffen die Parteien, den Konﬂikt regeln zu können? Oder haben sie jede Hoffnung

aufgegeben?

454

Team

4.4.10

Konfliktbewältigung

4.4.10.1

Das Ziel von Konfliktmanagement

Was bezweckt Konﬂiktmanagement? Können wir den Anspruch haben, all unsere oben

aufgeführten Konﬂiktarten zu „lösen“? Das würde ja bedeuten, dass all die unterschied-

lichen Überzeugungen, Sichtweisen, Bedürfnisse und Gefühle, die zur „Unvereinbarkeit

zweier Elemente“ geführt haben, sich plötzlich in Minne auﬂösen?

Da Konﬂikte immer einen persönlichen und emotionalen Anteil haben, ist deren Lö-

sung ein anspruchsvolles Ziel. Konﬂikte sind immer eine Herausforderung, welche aktiv

bearbeitet werden muss. Berkel beschreibt das Ziel des Konﬂiktmanagements:

Konﬂiktbewältigung zielt darauf ab, einen Konﬂikt so in den Griff zu kriegen und zu meis-

tern, dass die Person (Partei) in ihrem Erleben (nicht mehr) eingeschränkt und (wieder) voll

handlungsfähig ist (Berkel 2014, S. 72).

Konﬂikte sind immer Störungen, die sich zuerst in unseren Beziehungen zu ande-

ren Menschen manifestieren. Auf den ersten Blick ist ein Konﬂikt immer unangenehm:

Einerseits behindern Konﬂikte das persönliche, zielorientierte Streben des Menschen.

Andererseits aktivieren Konﬂikte auch immer die Grundgefühle Angst oder Ärger

(Abschn. 4.4.6.2). Die Gefühle des Menschen sind immer sehr viel schneller als der

Verstand. Menschen, die in Konﬂikten ihre Grundemotionen sofort ausleben, werden

schnell destruktiv. Das verhindert das unter Abschn. 4.4.5 beschriebene positive Potenzial

von Konﬂikten.

4.4.10.2

Die Selbststeuerung wiederherstellen

Im Konﬂikt ist unser Hirn erregt, weil die Situation, mit der es konfrontiert wird, nicht dem

entspricht, was es erwartet. In der Erregung verliert der Mensch seine Fähigkeit zur reﬂek-

tierten Selbststeuerung. Wenn das Hirn im wahrsten Sinne des Wortes „heiß“ läuft, muss

es wieder heruntergekühlt werden, um die reﬂektierte Selbststeuerung wieder zu ermögli-

chen. Das kann nur auf dem gleichen Weg erreicht werden, wie die Erregung entstanden

ist.

Die Herausforderung dabei ist, dass unsere Haltungen, Einstellungen und Bewertungen

im präfrontalen Kortex (Abschn. 3.3.2) auf einem gekoppelten Netzwerk mit kognitiven

und emotionalen Anteilen beruhen. Jede Position oder Forderung in einem Konﬂikt kann

also rational begründet werden. Sie fühlt sich aber auch an, ist emotional verankert.

Oft wird versucht, in einem Gespräch zwischen den Konﬂiktparteien eine neue Ab-

machung zu erzielen und damit Regeln für ein verändertes Verhalten festzulegen. Auch

wenn diese Abmachung inhaltlich noch so viel Sinn machen mag, passiert es oft, dass die

Parteien danach wieder in die alten Verhaltensmuster zurückfallen. Der Grund, weshalb

viele Konﬂikte nicht erfolgreich bewältigt werden, liegt darin, dass das Verhalten eines

Menschen auf dessen Haltung basiert. Diese Haltung ist geprägt durch den oben beschrie-

benen kognitiven und emotionalen Anteil. Konﬂiktbewältigung, die diese Anteile nicht

miteinbezieht, kann deshalb nicht erfolgreich sein.

4.4

Konfliktmanagement und Krisen

455

Konﬂiktparteien können ihre Selbststeuerung nur dann wiederherstellen, wenn sie auch

aus der emotionalen Erregung herauskommen. Hierfür muss ein Raum des Vertrauens

geschaffen werden, in welchem die involvierten Parteien sich sicher fühlen. Das Gefühl

der Sicherheit lässt die Gefühle abkühlen. In diesem neu geschaffenen Raum des Vertrau-

ens sollen die Menschen dann ermutigt oder gar inspiriert werden, neue Erfahrungen

mit Strategien und Verhaltungsmustern zu machen, deren Wirksamkeit sie in vergleich-

baren Situationen mit der gegenwärtigen Haltung bisher für unmöglich gehalten hatten

(Ballreich und Hüther 2009).

4.4.10.3

Prozess der Konfliktbewältigung

Beispiel

„Ein Mann will ein Bild aufhängen. Den Nagel hat er, nicht aber den Hammer. Der

Nachbar hat einen. Also beschließt unser Mann, hinüberzugehen und ihn auszuborgen.

Doch da kommt ihm ein Zweifel: Was, wenn der Nachbar mir den Hammer nicht leihen

will? Gestern schon grüßte er mich nur so ﬂüchtig. Vielleicht war er in Eile. Vielleicht

hat er die Eile nur vorgeschützt, und er hat was gegen mich. Und was? Ich habe ihm

nichts angetan; der bildet sich da etwas ein. Wenn jemand von mir ein Werkzeug borgen

wollte, ich gäbe es ihm sofort. Und warum er nicht? Wie kann man einem Mitmenschen

einen so einfachen Gefallen abschlagen? Leute wie dieser Kerl vergiften einem das

Leben. Und dann bildet er sich noch ein, ich sei auf ihn angewiesen. Bloß, weil er

einen Hammer hat. Jetzt reicht’s mir wirklich. – Und so stürmt er hinüber, läutet, der

Nachbar öffnet, doch bevor er „Guten Tag“ sagen kann, schreit ihn unser Mann an:

„Behalten Sie Ihren Hammer, Sie Rüpel!“

(Watzlawick 2004, S. 37 f.)

Die Hammer-Geschichte von Watzlawick zeigt auf: Der Mensch, beschäftigt mit sei-

nen eigenen Gedanken und Vorstellungen, gerät schnell in einen Teufelskreis. Je länger

wir schwierige Situationen mit uns herumtragen, desto größer wird die Gefahr, dass wir

uns unnötig in etwas hineinsteigern. Die Abb. 4.30 fasst die Voraussetzungen für eine

erfolgreiche Konﬂiktbewältigung zusammen.

Jeder der nachfolgenden Schritte illustriert den Prozess, wie ihn Berkel (2014) in seiner

kooperativen Konﬂiktbewältigung beschreibt (Abb. 4.30). Dieser beginnt bei der Person

selber, geht dann über in die Beziehung, damit schließlich auf der Sachebene die effektive

Problembearbeitung stattﬁnden kann.

Störung wahrnehmen

Da der Mensch Konﬂikte persönlich nimmt, beginnt die Konﬂiktbewältigung beim Men-

schen. Zuerst muss der Konﬂikt respektive die subjektiv empfundene Störung wahrge-

nommen werden.

Entweder melden sich die Konfliktparteien selber beim Projektverantwortli-

chen. Oder aber dieser interveniert aufgrund seiner persönlichen Wahrneh-

456

Team

Sache

Problem bearbeiten

Vereinbarung treffen

Beziehung

Vertrauen stiften

Offen kommunizieren

Person

Störung erkennen

Erregung kontrollieren

Wille zur Konﬂiktbearbeitung

Abb. 4.30 Prozess der Konﬂiktbewältigung. (Abgeleitet von Berkel 2014, S. 111 ff.)

mung oder Vermutung. Im Vordergrund steht hier die Äußerungsform des

Konflikts, die je nach Mensch und Situation ganz unterschiedlich sein kann.

Die Kenntnis des Konfliktsyndroms und der Konfliktsymptome leistet in dieser

Phase wertvolle Hilfe. Wichtig ist: Der Projektleiter kann nie wissen, ob eine Stö-

rung besteht und was die Gründe sein mögen. Er kann nur Hypothesen dazu

bilden und die involvierten Personen darauf ansprechen. Dieses Ansprechen

soll unbedingt in einem bilateralen Gespräch stattfinden. Es darf kein Druck

aufgebaut werden. Wenn die angesprochene Person einen Konflikt verneint

(weil es stimmt, oder weil die Person noch nicht in der Lage ist, darüber zu spre-

chen), muss er das so lange akzeptieren, wie die Leistungsfähigkeit des Teams

nicht beeinträchtigt wird. Sonst muss der Projektverantwortliche intervenieren.

Wille zur Konﬂiktbearbeitung

Die wesentliche Voraussetzung zur Konﬂiktbearbeitung liegt darin, dass alle involvierten

Parteien die Bereitschaft und den Willen für eine Bewältigung des Konﬂiktes zeigen. So-

lange nur eine Partei dies nicht will oder kann, wird die Konﬂiktbearbeitung nicht die

gewünschten Resultate liefern können. Die Herausforderung im Konﬂikt ist die, dass es

– nach der Konﬂiktdeﬁnition von Glasl – immer um subjektiv empfundene Differenzen

im Fühlen, Denken oder Handeln geht.

4.4

Konfliktmanagement und Krisen

457

Konflikte stören den Fortschritt des Projektes. Daher möchten Projektverant-

wortliche diese so schnell wie möglich aus der Welt schaffen. Die betroffenen

Menschen haben aber ganz unterschiedliche Bedürfnisse, Fähigkeiten und

Möglichkeiten, mit diesen Situationen umzugehen. Deshalb brauchen Scrum

Master oder Projektleiter in einem Konflikt genügend Geduld, um den Bedürf-

nissen der Betroffenen zuentsprechen.Ebenfallsmussesihnengelingen,genug

Dringlichkeit für das Thema zu erzeugen. Je länger der Konflikt dauert, desto

mehr intensiviert er sich, desto mehr Personen werden davon betroffen.

Erregung kontrollieren

Eine konstruktive Konﬂiktbewältigung ist in der Erregung nicht möglich (Abschn. 4.4.6).

Den betroffenen Parteien muss es wieder gelingen, den „Fahrstuhl nach oben“ zu aktivie-

ren, d. h. aus den archaischen Notprogrammen und den frühkindlichen Überlebensstrate-

gien in die Selbststeuerung zu gelangen. Die Gefühle zu unterdrücken oder zu verdrängen

verstärkt diese nur.

Aus dem Affekt führt ein Gespräch am besten zur Vernunft. Im Gespräch werden

Gefühle in (rationale) Worte gefasst. Durch das Reden über die eigenen Gefühle und Be-

dürfnisse oder auch durch das Paraphrasieren von Aussagen anderer (Konﬂikt-)Parteien

wird das Hirn gezwungen, rational zu denken. Wenn das Gespräch nicht möglich ist, hilft

das Schreiben. Schreiben aktiviert wie das Sprechen die rationalen Verhaltensmuster des

Menschen. Dies erlaubt es, zum eigenen Empﬁnden eine gewisse Objektivität zu entwi-

ckeln.

Der Projektverantwortliche – in schwierigeren Fällen ein neutraler Coach oder Me-

diator – kann einen Raum schaffen, in welchem die betroffene Person beschreiben kann,

wie es ihr geht und was aus ihrer Sicht zu der speziﬁschen Erregung geführt hat. Der

Projektverantwortliche muss hier gut zuhören können und sollte vertraut sein mit unter-

schiedlichen Fragetechniken (Abschn. 3.9.8).

In diesem Schritt geht es weder um eine Diagnose noch darum, Lösungen zu ent-

wickeln. Sehr viel wichtiger ist es, die eigenen und die fremden emotionalen Anteile

beschreiben zu können, weil Konﬂikte vielschichtig sind. Jetzt wird die Grundlage für

die Konﬂiktdiagnose geschaffen.

Je früher der Konflikt bearbeitet wird, desto einfacher fällt es den Parteien, ihre

Gefühle wahrzunehmen und diese einzuordnen. Je weiter ein Konflikt eskaliert,

desto schwieriger ist es für die involvierten Personen. Wichtig ist, dass die Be-

troffenen davon überzeugt werden können, dass die Gefühle nicht bekämpft

werden sollen. Dadurch werden sie noch intensiver, wie die Hammer-Geschich-

te von Watzlawick zeigt. Der Verantwortliche muss einen Raum schaffen, in dem

sich der Betroffene sicher fühlt. Je nach Situation und Eskalationsstufe kann es

sinnvoll sein, schon hier eine neutrale Drittperson in das Gespräch mit einzube-

ziehen. Folgende Fragen sind gemeinsam zu beantworten:

Was hat die Störung ausgelöst?

Welche Grundemotionen (Angst oder Ärger) sind aktiviert?

458

Team

Vertrauen stiften

Jetzt ist auf der Beziehungsebene zwischen den Konﬂiktparteien der oben beschriebene

Raum des Vertrauens (Abschn. 4.4.10.1) herzustellen. Wer Vertrauen erhalten will, muss

seine Maske fallen lassen, muss sich öffnen und seine Vorstellungen und Empﬁndun-

gen mitteilen können. Dieses Öffnen ist jedoch immer auch mit einem Risiko verbunden:

Offenheit und Ehrlichkeit können ausgenutzt werden. Deshalb ist es so wichtig, Rahmen-

bedingungen schaffen zu können, in denen sich die Parteien sicher fühlen.

Eine neutrale Drittperson hat einen großen Einfluss auf die gefühlte Sicherheit

in einer Konfliktbewältigung. Sei es der Projektverantwortliche selber, ein Coach

oder Mediator: Wenn die Parteien Vertrauen haben zu dieser Person, können sie

sich auf den Prozess einlassen. Wichtig ist, dass die Drittperson in ihrer Rolle von

allenKonfliktparteienakzeptiertwird.WeitersindRegelnfestzulegen,diefüralle

Parteien in diesem Prozess verbindlich sind. Hilfreich ist es, mit realistischen Vor-

schlägen der anderen Partei entgegenzukommen sowie sicherzustellen, dass

die persönlichen Motive und Absichten verstanden werden.

Offene Kommunikation

Direkt mit dem Vertrauen verbunden ist die offene Kommunikation. Auch diese spielt

sich auf der Beziehungsebene ab. Gute persönliche Kommunikationskompetenzen

(Abschn. 3.9) sind hierfür wesentlich:

Kommunikation ohne Wertung

Ich-Botschaft statt Du-Botschaft

Kommunikationsquadrat: Sich selbst offenbaren und die eigenen Anliegen in einer

Komplettbotschaft darlegen

Interpretationen vermeiden: Über aktives Zuhören und weitere Fragetechniken Ge-

sprächspunkte klären

Problem bearbeiten

Jetzt sind die Voraussetzungen für die effektive Problembearbeitung auf der Sachebene

geschaffen. Die konkreten Ansätze dazu sind in Abschn. 4.4.11 aufgeführt.

Vereinbarung treffen

Ansatzpunkte für eine nachhaltige Konﬂiktbewältigung sind konkrete Maßnahmen und

Tätigkeiten, das persönliche Verhalten oder auch eine Veränderung der persönlichen Be-

wertung (Abschn. 3.5.4).

Je klarer (oder „SMARTer“) die Vereinbarungen deﬁniert werden können, desto größer

ist die Wahrscheinlichkeit, dass die Konﬂiktbewältigung erfolgreich sein kann. In dieser

Phase sind kleine Schritte als Erfolg zu würdigen. Doch sollen sich die Parteien nicht

vorschnell mit speziﬁschen Resultaten zufriedengeben, sondern beharrlich dafür sorgen,

dass wahrnehmbare und nachhaltige Verbesserungen erzielt werden können.

4.4

Konfliktmanagement und Krisen

459

Umsetzung und

Kontrolle

Bestmögliche Alternative wählen

Ideen bewerten.

Ergebnis auf objektive

Entscheidungs-

prinzipien aufbauen

Kriterien

Kreative Wahlmöglichkeiten

für die gemeinsamen Interessen

Neue Lösungen

Möglichkeiten

Basis Konﬂiktdiagnose:

Was ist klar/unklar?

Übereinstimmung/

Differenz

Worum geht es?

Beziehung schützen

Vertrauen schaffen

Mensch und Sache trennen

Nicht in Positionen verharren, Gefühlen

Raum geben, Eigenbild und Fremdbild

Interessen und Bedürfnisse

Abb. 4.31 Konﬂiktbewältigung nach dem Harvard-Konzept

4.4.10.4

Harvard-Konzept in der Konfliktbewältigung

Hinter jedem Konﬂikt steht eine Verhandlung. Entweder ist sie gescheitert – oder sie hat nie

stattgefunden (Michael Bullinger).

Wenn wir den Konﬂikt sehen als zwei Elemente, die gleichzeitig unvereinbar oder ge-

gensätzlich sind, stellt sich die Frage, wie die beiden Elemente wieder verbunden werden

können. Dafür kann die Verhandlungsführung nach dem Harvard-Konzept einen wertvol-

len Beitrag leisten, siehe Abschn. 4.3.4. Die klare Trennung zwischen Person und Sache

erlaubt es, dass unter Aufrechterhaltung des Respekts für den Menschen inhaltlich hart

gestritten werden kann. Den Fokus auf die Interessen und Bedürfnisse zu richten erlaubt

es, ein Gleichgewicht zwischen den Konﬂiktparteien herzustellen. In Abb. 4.31 wird der

Prozess der Konﬂiktbewältigung – orientiert am Harvard-Konzept – dargestellt (Basierend

auf Fisher et al. 1999).

Mensch von der Sache trennen

Je nach Eskalationsstufe eines Konﬂiktes (Abschn. 4.4.9.1) sind die Konﬂiktparteien noch

ihren Grundemotionen Ärger oder Angst ausgesetzt. Es gilt deshalb, zuerst wieder einen

460

Team

Raum zu schaffen, in dem sich die Parteien sicher fühlen können und in dem sie Ver-

trauen ins Gegenüber und möglicherweise in die neutrale Vermittlungsperson entwickeln

können. Für diesen Prozess braucht jeder Mensch unterschiedlich viel Zeit.

Die oben beschriebenen Voraussetzungen für eine konstruktive Konfliktbe-

wältigung sind zu schaffen, bevor der Prozess beginnen kann.

Alle Konfliktparteien können ihre Bedürfnisse nennen und Bedingungen an

den Prozess stellen.

Rollen sind zu klären: Welche Konfliktparteien sind aktiv in den Prozess ein-

gebunden? Wer ist für den Prozess verantwortlich? Welche Aufgaben, Kom-

petenzen und Verantwortlichkeiten hat diese Person?

Regeln für den Prozess der Konfliktbewältigung sind zu vereinbaren: Welche

Regeln gelten für die Kommunikation? Wie gehen wir mit Regelverstößen

um? Wer ist der Schiedsrichter? Wer trifft welche Entscheidungen?

Je nach Eskalationsstufe desKonfliktesmüssen die Konfliktparteien eine neu-

trale Drittperson wählen, die durch den Prozess moderiert, oder gar eine Au-

torität, welche die Kontrahenten voneinander trennt.

Worum geht es?

In den allermeisten Konﬂikten besteht nicht über alles ein Dissens. In einem ersten Schritt

sollen in dieser Phase die Übereinstimmungen erkannt und geschützt werden.

In einem zweiten Schritt werden die effektiven Differenzen und damit Konﬂiktquellen

herausgearbeitet oder bestätigt. Idealerweise ist in dieser Situation die Konﬂiktdiagnose

(Abschn. 4.4.8) bereits durchgeführt. Ansonsten ist die Diagnose nun gemeinsam zu stel-

len.

Resultate der Konfliktdiagnose besprechen. Die effektiven Differenzen her-

ausschälen.

Sich nicht vorschnell mit einer Erkenntnis zufriedengeben: Die Situation, die

Rahmenbedingungen oder andere (abwesende) Personen wie den Chef, die

KundenoderdenLieferantenzubeklagen,fälltmeistensleicht.InjedemKon-

flikt haben die Beteiligten auch einen eigenen Anteil. Diesen eigenen Anteil

zu beleuchten, fällt meistens viel schwerer.

Von den Symptomen zu den Ursachen vorstoßen: Das systemische Phäno-

men (Abschn. 4.4.2) und den verschobenen Konflikt mit den Ersatzbefriedi-

gungen (Abschn. 4.4.8.2) berücksichtigen.

Interessen und Bedürfnisse

Vielfach sind Konﬂiktparteien so mit ihrem Ärger über die andere Partei oder mit ihrer

Angst beschäftigt, dass sie sich selbst nicht mehr spüren. Sie können kaum mehr sagen,

was ihnen fehlt und was sie brauchen. In dieser Phase müssen die Parteien den großen

Schritt machen können, sich aus der Ich-Bezogenheit zu lösen und das Eigenbild mit

dem Fremdbild zu ergänzen.

4.4

Konfliktmanagement und Krisen

461

Wenn die involvierten Parteien Berührungspunkte in gemeinsamen Interessen und Be-

dürfnissen erkennen können, ist die Voraussetzung für eine tragfähige Konﬂiktbewäl-

tigung geschaffen. Sie können sich aus der gegenwärtigen Position lösen und sich für

zukünftige Interessen und Bedürfnisse öffnen.

Beispiel

Robert Dilts hat dazu den Metamirror entwickelt. Den kann jemand allein oder mit ei-

nem Coach anwenden. In der Kurzform geht das so: Du stellst zwei Stühle einander

frontal gegenüber: Stuhl 1 für dich, Stuhl 2 für deinen Konﬂiktpartner. Du stellst dir

vor, dass dein Gegenüber auf Stuhl 2 sitzt. Du setzt dich auf Stuhl 1 und sagst deinem

Gegenüber, was du an ihm schätzt und was du in Zukunft von ihm anders erwartest.

Danach stellst du dich hinter Stuhl 1 und beschreibst dein eigenes Verhalten in Be-

ziehung zu deinem Konﬂiktpartner. Dann setzt du dich auf Stuhl 2: Wie nimmst du

in der Position deines Gegners deine Worte wahr? Was empﬁndest du? Welche guten

Absichten entdeckst du hinter dem Verhalten des Konﬂiktpartners? Jetzt stellst du dich

seitlich zu den beiden Stühlen. Beschreibe von dieser Metaposition aus die Interaktion

der beiden Personen. Wie beurteilst du dein eigenes Verhalten? Wie das deines Kon-

ﬂiktpartners? Wie gehen beide miteinander um? Welche Metapher beschreibt diesen

Umgang? Welche Ideen hast du aus dieser Position: Was möchtest du anders machen?

Welche Fähigkeiten kannst du dazu nutzen? Gehe nun zurück auf Position 2. Beurteile

die Lösungsidee aus dieser Perspektive. Zurück auf der 1. Position stellst du fest, wie

du die Kommunikation wahrnimmst. Was hat sich wie verändert? Verändere deine Po-

sition zwischen den Stühlen 1 und 2 solange, bis du mit deiner neuen Wahrnehmung

zufrieden bist. Stelle dir anhand einer konkreten Situation vor, wie du in Zukunft mit

dieser Person kommunizierst.

Die in Abb. 4.32 dargestellte Konﬂiktzwiebel veranschaulicht diese Differenzierung.

Sie arbeitet mit den am Konﬂikt beteiligten Personen direkt an weitreichenden Konﬂiktsi-

tuationen.

Durch lösungsorientierte Fragen kann ein positives Bild gezeichnet werden,

aufgrund dessen eine Verbesserung der Situation erreicht werden könnte:

„Woran könnten wir erkennen, dass der Konflikt bewältigt ist? Was wäre dann

anders im Vergleich zur aktuellen Situation?“

Zirkuläre Fragen können eine Partei auffordern, sich in die Perspektive der

anderen zu versetzen: „Wenn ich den Kollegen XY fragen würde, was denkst

du, liegt ihm wirklich am Herzen?“ Oder: „Welche Interessen verfolgt er mit

diesem Projekt, was ist ihm wirklich wichtig?“

Auch die Wunderfrage kann neue Perspektiven eröffnen: „Stell Dir vor, der

Konflikt ist bewältigt. Du arbeitest wieder motiviert und engagiert in deinem

Projekt: Woran könntest Du das erkennen?“

Zur Spiegelung und Klärung der Antworten kann immer wieder das Para-

phrasieren oder das aktive Zuhören angewendet werden.

462

Team

Interessen

Dinge, die eine Partei wirklich WILL

► Mittelfristige Wünsche

Positionen

Dinge, die eine Partei vorgibt, haben zu WOLLEN

► Kurzfristiger Fokus

Bedürfnisse

Dinge, die eine Partei braucht,

die sie haben MUSS.

► Langfristig zentral

Abb. 4.32 Konﬂiktzwiebel

Möglichkeiten

Je mehr Wahlmöglichkeiten zur Verfügung stehen, desto besser wird schließlich der ge-

troffene Entscheid. Diese Phase lebt davon, dass sich die Beteiligten aus ihren bestehenden

Denk- und Verhaltensmustern lösen können, um Lösungsansätze zu entwickeln, die mög-

licherweise noch nicht der gängigen Organisationskultur entsprechen. Alle Ansätze,

die es erlauben, den gemeinsamen Interessen ein Stück näher zu kommen, sollen erfasst

werden. Nur mit Fleiß und Druck wird es schwer, diese Möglichkeiten zu entwickeln.

Es braucht einen Überschuss an Aufmerksamkeit und damit einen Raum für Kreativität

(Abschn. 1.7.2).

Unter Zeitdruck sind kreative Lösungen schlecht möglich. Oft braucht es

mehrere Anläufe, um brauchbare oder gar hochwertige Varianten zu ent-

wickeln. Diesen Zeitbedarf müssen sich die Parteien und der Moderator

eingestehen.

Lösungsideen von externen Personen können in dieser Phase wertvoll sein.

4.4

Konfliktmanagement und Krisen

463

Kriterien

Die gemeinsame Diskussion objektiver Kriterien, die für die Auswahl der Verhandlungsal-

ternative angewendet werden können, erleichtert das Verlassen von Positionen und schmä-

lert die Grundlage für unfairen Druck.

Bei Sachkonflikten müssen die Projektverantwortlichen darauf achten, dass

die Entscheidungskriterien im Einklang sindmit den Anforderungen ausdem

Projektauftrag oder der Produktvision.

Für Lösungsansätze außerhalb der bestehenden Anforderungen nehme man

Rücksprache mit dem Product Owner oder dem Auftraggeber.

Bestmögliche Alternative wählen

Für die Auswahl der bestmöglichen Alternative eignet sich das BATNA-Prinzip, siehe

Abschn. 4.3.4.5. Wenn der Entscheid getroffen ist, ist das Wichtigste für Projektverant-

wortliche, von allen betroffenen Parteien für den gewählten Lösungsansatz Verbindlich-

keit einzufordern.

Im Sinne eines Maßnahmenplans wird festgelegt, wer was bis wann zu tun hat,

um die ausgewählte Lösung zu realisieren. Auch das Controlling obliegt den

Projektverantwortlichen: Sollten die Betroffenen mit ihren Beiträgen in Verzug

geratenoder sogar in alte Verhaltensmusterzurückfallen, muss das früh erkannt

werden. Darauf sind korrigierende Maßnahmen einzuleiten.

4.4.11

Konfliktbewältigung je nach Konfliktart

Die oben dargestellte grundsätzliche Herangehensweise zur Bewältigung von Konﬂik-

ten wird hier mit Empfehlungen zur Bewältigung speziﬁscher Konﬂiktarten gemäß

Abschn. 4.4.7 präzisiert.

4.4.11.1

Ziel- und Interessenkonflikt

Zielkonﬂikte

In einer frühen Phase im Projekt lassen sich Zielkonﬂikte über schriftliche Ziele klären,

die so gut wie möglich SMART formuliert sind. Diese Ziele sollten auch, im Sinne des

MbO, vereinbart und nicht einfach nur vorgegeben sein (Abschn. 4.1.13.4). Sollte ein

Zielkonﬂikt in einer späteren Projektphase auftreten, ist dieser über das Change Request

Verfahren zu bearbeiten.

Dabei sind immer die unterschiedlichen Kompetenzebenen der Projektgremien zu be-

rücksichtigen (Abschn. 2.3.9). Oft wirkt bei Ziel- oder Interessenkonﬂikten das systemi-

sche Phänomen, weil die Aufträge unklar oder widersprüchlich sind. Die Mankos eines

unklaren Auftrages manifestieren sich über kurz oder lang im Projektteam als Konﬂikte.

464

Team

Es gehört zur Aufgabe des Projektleiters, Differenzen oder Widersprüche in den Pro-

jektzielen aufzuzeigen und den Projektverantwortlichen Lösungsansätze vorzuschlagen.

Werden die Widersprüche nicht vom Auftraggeber, Projektleiter und Projektausschuss

(Entscheidungsträgern) angegangen, sondern in die Projektorganisation delegiert, mani-

festieren sie sich dann zwischen den Mitarbeitern.

Interessenkonﬂikte

Es ist sehr schwierig, alle unterschiedlichen Interessen der Stakeholder an ein Projekt

auf einen gemeinsamen Nenner zu bringen. Mit einer fundierten Stakeholder-Analyse

werden die divergierenden Interessen der Anspruchsgruppen sichtbar. So können sie be-

arbeitet werden.

Vor allem für Akzeptanz- und Pionierprojekte (Abschn. 1.2.1) ist die fortlaufende Be-

wirtschaftung der Stakeholder-Interessen eine wichtige Aufgabe, um Konﬂiktpotenziale

frühzeitig zu erkennen.

4.4.11.2

Verteilungs- und Ressourcenkonflikt

Jedes Projekt ist damit herausgefordert, mit personellen, ﬁnanziellen und technischen

Ressourcen seine Ziele zu erreichen. Diese Spannung kann nicht grundsätzlich aufgelöst

werden. Innerhalb des Projektes muss der Projektleiter antizipieren, Divergenzen aufzei-

gen und den Entscheidungsverantwortlichen Lösungen vorschlagen.

Oft müssen Projektleiter aber auch lernen, ihre Auftraggeber unter Druck zu setzen,

um die Ressourcen zugeteilt zu bekommen, die ihnen gemäß Projektauftrag zustehen.

Bei Ressourcenkonﬂikten wirkt auch das systemische Phänomen (Abschn. 4.4.2):

Wenn in der Linienorganisation unzureichende Ressourcenplanungen für die Mitar-

beiter gemacht werden, spiegelt sich das auch in den Projektteams wider. Wer seine

verfügbaren personellen Ressourcen nicht kennt, startet womöglich viel mehr Projekte,

als er bearbeiten kann. Werden die Ressourcenplanungen und -zuteilungen nicht auf der

Ebene der Entscheidungskompetenz im Projekt entschieden, wird der Konﬂikt in das

Projektteam delegiert. Die Konsequenzen daraus sind dann:

Beziehungskonﬂikt: Der Konﬂikt manifestiert sich zwischen Personen im Projektteam,

z. B. zwischen Projektleiter und Teilprojektleiter.

Persönlicher Konﬂikt: Der Projektleiter versucht, das Deﬁzit zu kompensieren. Damit

steigt die Belastung, es kommt zum Loyalitätsdilemma oder zu Motivationsproblemen.

In größeren Organisationen können das Multiprojektmanagement (Abschn. 2.7) und

ein Projektportfolio wesentliche Friktionspunkte entschärfen. Überallokationen von Ein-

zelpersonen werden im Multiprojektmanagement ersichtlich. Sie können nur mittels Prio-

risierung im Projektportfolio gelöst oder zumindest entschärft werden. Die Voraussetzung

dafür ist allerdings, dass die zuständigen Gremien auch ihre Verantwortung für das Multi-

projektmanagement wahrnehmen und – im Falle von Überallokationen – die notwendigen

4.4

Konfliktmanagement und Krisen

465

Entscheide fällen. Das bedeutet, dass laufende Projekte gestoppt, verlangsamt oder abge-

brochen werden.

4.4.11.3

Struktureller und organisatorischer Konflikt

Strukturelle Konﬂikte betreffen v. a. Projektorganisationen, die über eine Matrix oder

eine Koordination an die Stammorganisation angebunden sind (Abschn. 4.1.4). Dieses

Problem kann der Projektleiter zwar transparent machen. Eine Veränderung zu erwirken

ist allerdings sehr schwierig, da diese das Führungssystem der Stammorganisation be-

einﬂussen würde. Der Projektleiter kann höchstens über seinen Auftraggeber optimale

Rahmenbedingungen für seine Projektarbeit erwirken. Zudem muss er seinen Führungs-

stil entsprechend anpassen: In einer Koordination führt er lateral (Abschn. 4.1.13.2).

Werden strukturelle oder organisatorische Konﬂikte nicht verhandelt und entschieden,

sondern mit „faulen Kompromissen“ respektive mit „work arounds“ gelöst, werden Kon-

ﬂikte nur verlagert oder an andere Stellen delegiert.

4.4.11.4

Bewertungskonflikt

Der Mensch als nicht-triviales System ist unberechenbar. Er hat unterschiedliche Sicht-

weisen, Überzeugungen und kann seine Meinung ändern. Bewertungskonﬂikte können

vermieden werden, wenn vor jeder Entscheidungsﬁndung der Entscheidungsmodus

vorab festgelegt wird. Ein Konsensentscheid ist zwar ein ehrenwertes Ziel. Weil alle Be-

teiligten selten die gleiche Meinung haben, muss ein Konsens- oder auch der Mehrheits-

entscheid ein mögliches Szenario sein. In gewissen Situationen müssen sich Projektleiter

oder Auftraggeber auch das Vetorecht ausbedingen.

Die wichtigste Maßnahme, um Bewertungskonﬂikte zu vermeiden, bildet der Projekt-

auftrag. Der Projektleiter ist dafür verantwortlich, dass er diesen so lange klärt und ver-

handelt, bis er völlig klar ist und er weiß, an welchen Zielen er gemessen wird. Auch die

Projektorganisation mit der RACI-Matrix oder dem Funktionendiagramm hilft, frühzei-

tig festzulegen, wer bei welchem Lieferobjekt oder Arbeitspaket welche Verantwortungen

und Entscheidungskompetenzen hat. Über diese Tabellen wird auch klar, welche Entschei-

dungskompetenzen der Auftraggeber für sich beansprucht und was er ins Projektteam

delegiert.

Für den Projektleiter steht die Prozesskompetenz im Vordergrund. Anträge für Fachent-

scheide muss er seinen Experten im Team delegieren können, weil er das Fachwissen dazu

nicht hat.

Verschärfen sich in einem Scrum Team unterschiedliche Überzeugungen und Sicht-

weisen, ist es die Aufgabe des Scrum Masters, zu intervenieren und zu vermitteln. Die

Retrospektive bildet die Plattform, auf der mögliche Diskrepanzen sichtbar gemacht und

bearbeitet werden.

466

Team

4.4.11.5

Rollenkonflikt

Rollenkonﬂikte gibt es auf zwei Ebenen:

Formale Ebene zur Ausgestaltung der Rollen: WAS sind die Aufgaben und Verant-

wortlichkeiten des Projektleiters oder Product Owners (Abschn. 4.1.9)?

Informale Ebene der gelebten Rolle: WIE wird diese Rolle ausgefüllt? WIE ist die

Schnittstelle zwischen Organisation und Person ausgestaltet (Abschn. 4.1.11)?

Formale Ebene

Die formale Ausgestaltung der Projektrollen im klassischen Ansatz ist bekannt (Abschn.

2.3.9.2), allerdings variiert diese stark je nach der Anbindung des Projektes an die

Stammorganisation: Ist das Projekt über eine Koordination an die Stammorganisation

eingebunden, hat der Projektleiter fast keine Entscheidungskompetenzen. Er ist als

Koordinator dafür verantwortlich, dass die entsprechenden Linienverantwortlichen die

relevanten Informationen und Entscheidungsgrundlagen erhalten. In der Matrix-Integra-

tion ist die Abstimmung mit den Linienvorgesetzten ebenfalls anspruchsvoll, v. a. dann,

wenn der Projektplan in Bewegung gerät und Ressourcen neu geplant werden müssen.

Grundsätzlich können formale Rollenkonﬂikte über einen fundierten Projektauftrag

verhindert oder auch im Nachhinein geklärt werden. Ebenfalls liefert die RACI-Matrix

oder das Belbin-Teamrollen-Konzept hier wertvolle Dienste.

Die formalen Rollen in agilen Projektteams sind klar deﬁniert. Agiles Projektmanage-

ment wird idealerweise in reiner Projektorganisation abgewickelt. Bei voller Konzentrati-

on der Kräfte auf das Projekt funktioniert die Selbststeuerung am besten.

Schwierig ist für den Product Owner, wenn er nicht mit den Entscheidungskompe-

tenzen ausgestattet ist, die Sprint-Resultate seines Teams abzunehmen. Ist er in seinen

Entscheiden abhängig von irgendwelchen Gremien der Stammorganisation, verlangsamt

das den Projektfortschritt. Auch verliert der Product Owner dadurch seinen Status gegen-

über dem Team. Er muss sicherstellen, dass er selber genügend Ressourcen hat für seine

Aufgabe. Beide Aspekte sind mit den Entscheidungsverantwortlichen der Stammorgani-

sation zu klären.

Informale Ebene: Gelebte Rolle

Die gelebte Rolle ﬁndet im Berührungspunkt zwischen Organisation und Person statt

(Abschn. 4.1.11). Die Organisation setzt sich zusammen aus mehreren Rollensendern.

Als Rollenträger bringt jeder Mensch seine einzigartige Person, seinen Charakter und

seine Prägung in die Projektrolle ein, wie auch immer sie inhaltlich deﬁniert ist. Manch-

mal senden wir Menschen Nachrichten aus, die uns nicht bewusst sind. Zudem können

wir nie wissen, wie wir auf andere Menschen wirken.

Wollen wir Konﬂikte in Bezug auf die gelebte Rolle klären, sind wir darauf angewie-

sen, dass wir Selbstbild und Fremdbild immer wieder abgleichen können. Deshalb sind

unsere Kommunikationskompetenzen grundsätzlich wichtig. Wir sind darauf angewiesen,

dass wir immer wieder von unseren Kollegen Feedback erhalten (Abschn. 3.9.7) und mit

4.4

Konfliktmanagement und Krisen

467

diesem konstruktiv umzugehen. Damit wir uns ein besseres Bild davon machen können,

wie wir auf andere Menschen wirken, sind auch die Belbin Teamrollen hilfreich. Der An-

satz betont, dass es ganz unterschiedliche Kompetenzen in einem Team braucht. Zudem

erlaubt er, über den Vergleich von Selbsteinschätzung und Fremdeinschätzung Unterschie-

de zu erkennen und diese zu bearbeiten.

4.4.11.6

Persönlicher Konflikt

In Abschn. 4.4.2 ist ausgeführt, dass sich Konﬂikte als Konsequenz des systemischen

Phänomens vordergründig als persönliche und soziale Konﬂikte manifestieren. Fehlende

Ressourcenplanungen, nicht geklärte Projektprioritäten (Projektportfolio) und die Abstim-

mung zwischen den Projektverantwortlichen und den Linienvorgesetzten (Projektkoor-

dination und Matrix) sind oft Ursachen, dass Konﬂikte aus der Organisation in das

Projekt delegiert werden und damit die einzelnen Personen herausfordern.

Bewältigt werden kann dieser Konﬂikt, wenn sich der Projektverantwortliche als

Symptomträger erkennt und es schafft, den Konﬂikt an die verursachende Stelle zurück-

zuweisen. Im optimalen Fall erkennen Auftraggeber oder die Linienvorgesetzten, dass

im Bereich des Change Request Managements Handlungsbedarf besteht: Die Qualität der

Projektarbeit ist sicherzustellen und die betroffenen Projektbeteiligten sind vor Konﬂikten

zu schützen. Um dieses optimale Resultat zu erreichen, braucht der Projektverantwortliche

hohe Kompetenzen im Bereich der Verhandlungsführung Abschn. 4.3.

Die Herausforderung ist in dieser Situation, dass bei einem delegierten Konﬂikt die

Handlungsverantwortung beim Symptomträger ist und nicht bei der Partei, die für die

Ursache des Konﬂiktes verantwortlich ist. Das bedeutet, dass sich der Symptomträger

in all dem operativen Druck der Projektabwicklung noch Zeit nehmen muss für diesen

delegierten Konﬂikt. Damit beginnt ein Vermeidungs-Vermeidungskonﬂikt. Je mehr Zeit

sich eine Person nimmt für die Bekämpfung der Ursache, desto weniger Zeit hat sie für

andere Verpﬂichtungen.

Im Vermeidungs-Vermeidungskonflikt sind die Personen in einem Dilemma.

Dieses kann oft weder aufgelöst werden, noch dürfen die betroffenen Personen

an sich die Erwartung haben, dass es eine gute Lösung geben kann. Kann die

äußere Situationnicht verändert werden (z.B.wenn kein strukturiertesChange

Request Management eingerichtet wird), bleiben noch folgende Möglichkeiten

(Abschn. 3.5.4):

Das eigene Verhalten verändern und Change Requests ab einer bestimm-

ten Projektphase nicht mehr akzeptieren. Mit diesem Verhalten geht der Pro-

jektverantwortliche natürlich ein Risiko ein, weil es nicht der gängigen Pro-

jektmanagement-Kultur entspricht und damit von Linienvorgesetzten oder

Mitarbeitern sanktioniert werden könnte.

Die Bewertung verändern und damit akzeptieren, dass permanente Ver-

änderungen am Scope in dieser Organisation zum Alltag gehören, mit allen

Konsequenzen für das Projekt selber wie auch für die eigene Person.

468

Team

Natürlich kann man auch versuchen, die ganze Sache zu verdrängen. Meis-

tens funktioniert das in der Projektarbeit nur kurzfristig, weil alle Arten von

Versäumnissen und Defiziten einen Einfluss auf das magische Dreieck haben

und damit sichtbar werden über Zeitverzögerungen, Budgetüberschreitun-

gen oder Reduktion des Scope.

Im schlimmsten Fall, wenn trotz des Versuchs der Neubewertung der persön-

liche Stress immer mehr zunimmt, muss sich die betroffene Person sogar vor

einer unkontrollierbaren Stressreaktion schützen (Abschn. 3.5.7) und die Projekt-

verantwortung abgeben oder gar die Stelle wechseln.

4.4.11.7

Beziehungskonflikt (sozialer Konflikt)

Kommunikation

Innerhalb des sozialen Konﬂiktes haben die verbale und nonverbale Kommunikation im-

mer Friktionspotenzial. Der bekannte Satz „Ich weiß erst, was ich gesagt habe, wenn ich

die beim Empfänger angekommene Botschaft kenne“ fordert uns immer wieder neu dazu

auf, uns für die subjektive Wahrheit des Gegenübers zu öffnen.

Die beste Bewältigung eines Kommunikationskonﬂiktes ist das direkte Gespräch.

Dabei ist zwischen Wirkung und Wertung zu differenzieren. Wie im Konﬂiktsyndrom

(Abschn. 4.4.3) dargestellt, leidet die Kommunikation immer in Konﬂikten. Damit ist

sie auch eine wirkungsvolle Intervention. Kommunikationskompetenzen zu entwickeln,

sollte für alle Projektbeteiligten selbstverständlich sein. Die Projektverantwortlichen sind

zudem aufgefordert sicherzustellen, dass in den Teams regelmäßige Kommunikations-

möglichkeiten installiert sind.

Nähe versus Distanz

Projektleiter und Product Owner übernehmen eine Führungsfunktion. Dadurch sind sie

darauf angewiesen, dass sie Weisungsbefugnis und Entscheidungskompetenzen gegen-

über ihrem Team haben. Je besser die Rolle geklärt und der Auftrag formuliert ist, desto

geringer sollte das Friktionspotenzial sein. Alle Beteiligten sollen sich aber immer wieder

bewusst machen, wer, wann in welcher Rolle ist. Vor allem wenn Projektleiter und Pro-

duct Owner früher Arbeitskollegen waren, müssen sie ein gutes Gefühl dafür entwickeln,

wann sie noch Kollege sein können und wann sie mehr auf Distanz gehen müssen, um

ihrer Verantwortung und Rolle gerecht zu werden.

Revier

Ein Projektteam in seiner interdisziplinären Zusammenarbeit hat immer den Auftrag, ver-

schiedene Kompetenzbereiche und damit Territorien zu verbinden. Oft hat das Projektziel

Konsequenzen auf bestehende Reviere, sei das bei Entwicklungsprojekten auf die Produk-

tion oder bei Veränderungsprojekten auf die Prozesse der Linienorganisation. Dies fordert

immer die bestehenden Machtgefüge heraus. Projektverantwortliche haben oft nicht die

4.4

Konfliktmanagement und Krisen

469

Macht, diese Spannungen selber zu bearbeiten. Vielmehr müssen sie sich im Rahmen des

Mandates die Unterstützung der Entscheidungsträger sicherstellen.

Rangordnung

Oft haben Projektverantwortliche nicht den gleichen Status wie die Verantwortlichen in

der Stammorganisation. Möglicherweise sind im Team auch Personen, welche in der

Stammorganisation höher angesiedelt sind als die Projektverantwortlichen. Werden Pro-

jektverantwortliche nicht in ihren Rollen anerkannt, sind sie wirkungslos. Auch hier geht

es darum, dass sie von ihren Entscheidungsträgern unterstützt werden und dass sämtli-

chen im Projekt involvierten Personen bewusst ist, welche Linienvorgesetzten hinter dem

Projekt stehen. Gute Wirkung zur Klärung der Rangordnung wird jeweils schon im Kick-

off erzielt: Ist der Auftraggeber präsent und setzt vor dem versammelten Projektteam den

Projektleiter oder Product Owner ofﬁziell in seine Rolle ein, sind diese Rollen weit wir-

kungsvoller, als wenn das nicht geschieht.

Führung

Product Owner und Projektleiter sind anspruchsvolle Führungspositionen. Oft haben sie

sich über ihre Expertenrolle für diese Aufgaben qualiﬁziert. Ihre Kompetenzen sind in die-

ser Situation weitgehend technisch-inhaltlicher Natur. Dies reicht allerdings noch nicht

für die Herausforderungen, die Product Owner und Projektleiter zu bewältigen haben.

Hier sind Prozess- und Entscheidungskompetenzen gefragt. Die Projektverantwortli-

chen, die nicht loslassen können von den technischen Details, demotivieren ihre Teams

und sorgen für Verwirrung. Dies kommt dann oft in Beziehungskonﬂikten zum Ausdruck.

Wie gehen wir damit um, wenn die Chemie nicht stimmt? Wenn der Pro-

jektleiter einen seiner Teilprojektleiter unsympathisch findet und bei jeder

Begegnung negative Gefühle entwickelt? In solchen Situationen hilft die Fä-

higkeit zur Selbstreflexion gemäß Abschn. 3.3.6: Unsere eigenen Gefühle haben

viel mehr mit uns selber zu tun als mit den anderen Menschen. Die Gründe,

warum dem Projektleiter ein Teilprojektleiter unsympathisch erscheint, können

vielfältig sein:

Der Teilprojektleiter kann ganz andere Charaktereigenschaften haben als

der Projektleiter. Ist der Projektleiter im Sinne der Belbin Teamrollen z. B. ein

starker Macher und der Teilprojektleiter ein starker Perfektionist, hat dies

Konfliktpotenzial (Abschn. 3.10.2).

Projektleiter und Teilprojektleiter weisen unterschiedliche Ausprägungen

ihrer Grundbedürfnisse aus. So können z. B. ein hohes Bedürfnis nach Sta-

tus und Anerkennung auf ein starkes Bedürfnis nach Geborgenheit prallen

(Abschn. 3.3.3).

Möglich ist auch, dass es sich um eine Projektion handelt: Der Projektleiter

projiziert einen eigenen Schatten oder ein Unvermögen auf den Teilprojekt-

leiter. Sollte der Projektleiter nicht in der Lage sein, eine solide Projektpla-

470

Team

nung zu machen – und dies als eigene Schwäche anzunehmen und zu ak-

zeptieren –, könnte dieser dem Teilprojektleiter vorwerfen, unzuverlässig zu

sein und seinen Verbindlichkeiten nicht nachzukommen. Vielleicht hat der

Teilprojektleiter aber das falsche Gesicht, den falschen Namen oder sonst ei-

ne Eigenart, die den Projektleiter unbewusst an eine Person erinnert, mit der

er einmal schlechte Erfahrungen gemacht hat.

In allen Situationen sind zunächst die Gefühle zuzulassen und nicht zu bekämp-

fen. Dann können sie, im Sinne einer Selbstreflexion, eingeordnet und auch

bewertet werden. Da der Projektleiter mit seinem Teilprojektleiter „nur“ auf ei-

ner professionellen Ebene zusammenarbeiten muss, ist Sympathie nicht zwin-

gend nötig. Es genügt, wenn der Respekt da ist und die Ziele, die vereinbart

wurden, erreicht werden. Hierfür sind Rollenklärung und ein adäquater Füh-

rungsstil nötig. Für die wesentlichen Bedürfnisse nach Zuneigung, Sympathie

und Liebe sind Beziehungswelt und Eigenwelt da (Abschn. 3.10.1). Es wäre eine

Überforderung, diese Ansprüche im beruflichen Umfeld befriedigen zu wollen.

Man muss aufhören, sich selber zu hinterfragen, und annehmen können, dass

mit einer spezifischen Person die Chemie nicht stimmt. Wenn im Sinne der per-

sönlichen Veränderungsstrategien (Abschn. 3.5.4) Verdrängung der Antipathie

und Neubewertung der Situation nicht möglich sind, bleibt noch, die Situation

zu verändern, indem der Kontakt zu dieser Person reduziert oder abgebrochen

wird.

4.4.11.8

Wertekonflikt

Werte sind ein wesentlicher Teil unsere Persönlichkeit. Das erklärt, weshalb es so schwie-

rig ist, Wertekonﬂikte zu bewältigen. Jeder Tugend steht eine Schwestertugend gegenüber.

Solche Wertepaare sind z. B. Vertrauen und Vorsicht, Durchsetzung und Rücksicht oder

Struktur und Flexibilität. In der Balance beider Tugenden zu sein, beide Eigenschaften

leben zu können, bedeutet Professionalität.

Werte werden Unwerte

Jeder Wert hat auch eine negative Übertreibung, wie im Wertequadrat nach Schulz von

Thun Abb. 4.33 dargestellt. Als Beispiel dient der Wert der strukturierten Arbeit, wie sie

in monochronen Organisationskulturen im Vordergrund steht (Abschn. 4.1.14.4). Struk-

turiert arbeiten zu können, ist in der Projektabwicklung wichtig. Die ganze Projektab-

wicklung, agil und klassisch, basiert darauf. Aber es gibt auch ein „zu viel des Guten“.

Das wird als (entwertende) Übertreibung bezeichnet. Ebenso wichtig ist es aber auch, bei

Veränderungen oder Problemen von Planungen abzuweichen oder „Umwege“ gehen zu

können, also ﬂexibel zu sein. Hier wäre die Übertreibung dann, alle Planung wegzulassen

und chaotisch vorzugehen.

4.4

Konfliktmanagement und Krisen

471

Das Netz der Beziehungen zwischen den vier Polen des Wertequadrats

ﬂexibel

pedantisch

chaotisch

positives Spannungsverhältnis

Überkompensation

entwertende Übertreibung

strukturiert

Entwicklung

Abb. 4.33 Beispiel Wertequadrat für strukturierte Arbeitsweise

Beispiel

Wer in einem klassischen Projekt Tätigkeiten im Detail plant, die in zehn Monaten

stattﬁnden sollen, ist pedantisch. Der Planungsaufwand ist enorm. Das Risiko, dass

sich daran noch etwas verändern wird, ist sehr groß.

Der konträre Gegensatz zur strukturierten Arbeit ist ﬂexibles Vorgehen. Dazu ist chao-

tische Arbeit die konträre Übertreibung zum pedantischen Arbeiten. Damit gibt es zwei

neue Paare: die strukturierte Arbeit steht in einem positiven Spannungsverhältnis zur ﬂe-

xiblen Arbeit. Die jeweilige Übersteigerung ergibt das negative Wertepaar von pedantisch

und chaotisch.

Die Entwicklung besteht darin, dass man beide Werte als Tugenden nutzen kann. Die

Gefahr ist jedoch groß, dass man sich in der Übertreibung der Schwestertugend verrennt.

Dies im Bestreben, die andere, einem nicht so geläuﬁge Tugend möglichst gut zu erfüllen

(Überkompensation). Der konstruktive Umgang mit solchen Wertekonﬂikten bedeutet die

gleichzeitige Entwicklung beider Schwestertugenden. Das bringt die menschlichen Qua-

litäten ins Gleichgewicht.

472

Team

Erwartungen mit den Ent-

scheidungsträgern klären

Verhandeln

Dilemma bewirtschaften

Multiprojektmanagement

Projektportfolio

Anbindung des Projekts

an die Stammorganisation

Rollen klären

RACI Matrix

Auf gemeinsame

Verhaltensregeln einigen

Ziele und Interessen

Verteilung und Ressourcen

Struktur und Organisation

Bewertung

Rolle

Beziehung

Person

Werte

Abb. 4.34 Strategien der Konﬂiktbewältigung je Konﬂiktart

4.4.11.9

Zusammenfassung Konfliktbewältigung

Die Übersicht in Abb. 4.34 fasst eine kleine Auswahl an Strategien und Ansätzen zusam-

men, die für die Bewältigung speziﬁscher Konﬂiktarten hilfreich sein können.

4.4.12

Konfliktprävention

Da Projektarbeit sehr konﬂiktanfällig ist, sind hier Möglichkeiten einer bestmöglichen

Prävention aufgezeigt.

4.4.12.1

Projektmanagement Methodik

Entweder suchst du den Konﬂikt zu Beginn des Projektes, oder er ﬁndet dich während der

Abwicklung.

Die mit Abstand wirkungsvollste Prävention auf der Ebene der Ursachen ist für uns

Autoren eine sorgfältige Anwendung der Projektmethodik. Sind Ziele oder Visionen

klar, Interessen der Stakeholder analysiert, Projektstrukturplan und Detailplanung mit den

4.4

Konfliktmanagement und Krisen

473

Aufwandschätzungen unterlegt, die Projektorganisation festgelegt, die Verfügbarkeit der

Ressourcen geklärt und Kommunikationsplattformen eingerichtet, haben Konﬂikte wenig

Nahrung.

Finden sich in diesen Unterlagen widersprüchliche oder unvereinbare Elemente, sind

sie methodisch transparent zu bearbeiten. Wenn nicht, wird sich das Konﬂiktpotenzial

nicht einfach auﬂösen, sondern in einer späteren Projektphase – und dann in einer höheren

Intensität – entfalten.

4.4.12.2

Störungen haben Vorrang

Das Konﬂiktsyndrom in Abschn. 4.4.3 ermöglicht uns, die Prävention da anzusetzen, wo

die Konﬂikte eskalieren können: offen kommunizieren, verzerrte Wahrnehmungen einan-

der gegenüberstellen und zurechtrücken, vertrauensbildende Maßnahmen ergreifen und

die gemeinsamen Ziele bestärken. Auch Verhaltensänderungen von Personen im Projekt-

team – und damit Konﬂiktsymptome (Abschn. 4.4.4) sind Frühindikatoren für Störungen.

Projektleiter und Scrum Master müssen sich für diese Frühindikatoren von Konﬂikten sen-

sibilisieren. Ein Postulat der Themenzentrierten Interaktion (TZI) nach Ruth Cohn heißt:

„Störungen haben Vorrang“: Je früher diese bearbeitet werden, desto einfacher wird es

sein, Bewältigungsstrategien zu entwickeln, die für alle involvierten Parteien zufrieden-

stellend sind. Je länger gewartet wird, desto höher wird die Intensität der Konﬂikte, wie

dies in den Eskalationsstufen in Abschn. 4.4.9.1 ausgeführt ist.

Die wesentliche Maßnahme, um diese Eskalationen im Keime zu ersticken, bildet

das Informations- und Kommunikationskonzept (Abschn. 2.4.10.2). Wenn alle internen

und externen Stakeholder erfasst und bewertet sind, müssen zielführende Plattformen für

die Kommunikation installiert werden. Diese – ergänzt mit den Kompetenzen der per-

sönlichen Kommunikation (Abschn. 3.9) – bilden das Fundament der Zusammenarbeit.

Sitzungen dienen auch der Kommunikation und dem Beziehungsaufbau, der Beziehungs-

pﬂege. Über Beziehung entsteht Vertrauen. Vertrauen ermöglicht den offenen Dialog und

eine Kultur, in welcher im Sinne von „Hart in der Sache, weich gegenüber dem Menschen“

für die beste Lösung gestritten werden kann.

4.4.12.3

Konfliktfähigkeit und Frustrationstoleranz

Zwei Kompetenzbereiche auf der persönlichen Ebene schließen das Kapitel ab.

Konﬂiktfähigkeit

Die Konﬂiktfähigkeit einer Person zeigt sich darin, inwiefern sie diese Konﬂikte aus-

halten und fair bewältigen kann. Konﬂiktfähigkeit basiert auf der persönlichen Haltung,

dass jede noch so schwierige Situation irgendwie bearbeitet werden kann und dass aus

jedem Konﬂikt ein Nutzen entstehen kann. Diese Haltung steht in engem Zusammen-

hang mit der Resilienz (Abschn. 3.8.4). Konﬂiktfähige Menschen sind davon überzeugt,

dass die im Konﬂikt entwickelte Energie positiv eingesetzt werden kann. Unterschiede

und Differenzen werden als integrale Bestandteile des Lebens aufgefasst. Konﬂikte wer-

den gewinnbringend bewältigt mit der Überzeugung, dass die Arbeit an den Differenzen

474

Team

Tab. 4.19 Grundannahmen zur Konﬂiktfähigkeit. (Glasl 2008, S. 13)

Konﬂiktscheu

Konﬂiktfähigkeit

Streitlust

Konﬂikte kosten nur Kraft,

darum: Hände weg davon!

Aggressionen sind Energie:

Ich leite sie positiv um!

In Konﬂikten erlebe ich mich

selbst – sie steigern Vitalität!

Offene Konﬂikte zerstören

unnötig vieles!

Konﬂikte helfen, sich von

alten Gewohnheiten zu lösen!

Nur aus Chaos entsteht wirk-

lich Neues!

Konﬂikte vertiefen nur die

Gegensätze. Differenzen sind

im Grunde doch nicht lösbar!

Unterschiede sind lebens-

notwendig, das Arbeiten an

Differenzen bereichert alle!

Konsens ist oft Illusion, denn:

„Der Krieg ist der Vater aller

Dinge!“

Menschen und Organisationen weiterbringen. In einem „Entweder-oder“-Denken ist das

nicht möglich. Der Mensch muss sich im Umgang mit Polaritäten auf das „Sowohl-als-

auch“ einlassen können (Abschn. 4.1.14.4). Die Tab. 4.19 stellt die Konﬂiktfähigkeit als

Bindeglied zwischen Konﬂiktscheu und Streitlust dar.

Das übertriebene Gute wird zum Bösen (F. Glasl).

Frustrationstoleranz

Frustrationstoleranz als Kompetenz wird den Menschen zugewiesen, die nicht immer

die eigenen Ziele durchsetzen müssen (Kreyenberg 2005, S. 219). Schwestertugend der

Konﬂiktfähigkeit ist die Frustrationstoleranz. Schon kleine Kinder müssen lernen, dass sie

nicht alles haben können, dass es nicht immer so läuft, wie sie es sich wünschen. Das ist

im Berufsleben auch so. Es gibt Kunden, Vorgesetzte und Organisationskulturen, welche

nicht unserem Ideal entsprechen. Wir müssen immer wieder auch einsehen können, dass

wir einerseits begrenzt sind in unseren Möglichkeiten und Fähigkeiten und andererseits,

dass die Projektorganisation nicht perfekt funktionieren wird.

4.4.13

Umgang mit Krisen

Krisen sind plötzliche und unerwartet eintretende Ereignisse, die mit den üblichen und mehr

oder weniger standardisierten Managementmethoden nicht bewältigt werden können (Wasti-

an et al. 2009, S. 292).

In jedem Projekt können Krisen entstehen. Eine Projektkrise ist eine Situation, in welcher

der Projektfortschritt blockiert oder stark eingeschränkt und die Erreichung des Projekt-

ziels gefährdet ist. Damit verlangt eine Krise auch eine sofortige Intervention. Dies ist

eine nicht delegierbare Führungsaufgabe der Projektverantwortlichen.

Eine Krise kann ihren Ursprung in der (Projekt-)Organisation selber haben. Oft sind

sie jedoch durch Bedingungen von außerhalb der Organisation ausgelöst.

4.4

Konfliktmanagement und Krisen

475

Interne Krisenursachen

Es gibt eine Reihe von Warnsignalen bzw. Indikatoren für sich anbahnende Krisen. Bei-

spiele: sich aufsummierende Kostenüberschreitungen, unfertige Teilergebnisse, fehlende

Entscheidungen, schwindende Motivation und fehlendes Engagement der Projektbeteilig-

ten, Hilferufe aus dem Projekt.

Krisen sind Ausnahmesituationen und brauchen daher ein spezielles Vorgehen und eine

adäquate Organisation. Die Bearbeitung von Krisen erfolgt in verschiedenen Phasen.

Folgende Maßnahmen können helfen, interne Krisenursachen so früh wie möglich zu

erkennen und zu bearbeiten:

Sorgfältiges und periodisches Risikomanagement und Controlling von „Scope“, „Zeit“

und „Kosten“.

Indizien für das Konﬂiktsyndrom (Abschn. 4.4.3) und für Konﬂiktsymptome (Abschn.

4.4.4) sowie Aspekte aus der Gruppendynamik (Abschn. 4.2) erkennen und bearbeiten.

Offene Gesprächskultur, regelmäßige persönliche Absprachen sowie Maßnahmen in

Bezug auf die Konﬂiktprävention.

Externe Krisenursachen

Trotz aller Vorsicht und Professionalität können Projektkrisen ganz unvermittelt von au-

ßen auf Projektteams treffen. Gründe dafür können sein, dass Projektbeteiligte eine Krise

in ihrem persönlichen Umfeld erleiden. Das kann ihre eigene Arbeitsfähigkeit lähmen und

sich auch auf das Team übertragen. Es kann aber auch ein wichtiger Lieferant ausfallen,

ein Kunde bankrottgehen oder ein Hacker-Angriff die gesamte Infrastruktur lahmlegen.

Große Organisationen betreiben Krisenstäbe, welche sich auf Worst-Case-Szenarien vor-

bereiten. Projektorganisationen sind hierfür jedoch zu klein.

Folgende Maßnahmen können helfen, externe Krisenursachen so früh wie möglich zu

erkennen und zu bearbeiten:

Regelmäßiges und aktives Stakeholdermanagement;

Maßnahmen aus dem Risikomanagement wie Bonitätsprüfungen oder Zweitlieferan-

ten;

Schnelle Intervention und Hilfestellungen, wenn Projektbeteiligte eine persönliche Kri-

se erleben.

Im Moment der Wahrnehmung einer Krise sollte der aktuelle Zustand so gut wie

möglich dokumentiert werden. So wie die Polizei bei einem Autounfall sofort

Beweis-Fotografien macht. Sollte z. B. ein Product Owner ausfallen und durch

eine andere Person ersetzt werden, ist im Moment der Übernahme eine um-

fassende Ist-Aufnahme von Produktkonzept, Product Backlog, Releaseplan und

auch von den aufgelaufenen Kosten zu machen.

476

Team

Tab. 4.20 Leitsätze in der Krisen-Kommunikation

Informieren Sie als Führungskraft ...

Informieren Sie konkret über ...

Aktiv und nicht reaktiv,

Opfer

Rasch und kontinuierlich,

Schaden

Zuerst immer direkt Betroffene,

Konsequenzen

Wahrhaftig und empathisch.

Sofortmaßnahmen

Kein „no comment“!

Untersuchungen

Alter (2008) S. 120

Führung und Kommunikation

Krisen sind Chefsache. Projektleiter, Scrum Master und Product Owner müssen sich

ihrer sofort annehmen. Auch ihre Vorgesetzten in der Linienorganisation haben sie um-

gehend in Kenntnis zu setzen. Eine Task Force muss gebildet werden, die verantwortlich

ist für die Bewältigung der Krise. Je nach Beurteilung der Situation müssen darin die

verantwortlichen Hierarchieebenen vertreten sein.

Krisen verunsichern. Sie generieren Ängste. Deshalb ist in Krisensituationen die Kom-

munikation zentral. Orientieren Sie Ihre Kommunikation in Krisen an den Leitsätzen in

Tab. 4.20.

4.5

Veränderung und Widerstand

Fast jedes Projektvorhaben führt zwangsläuﬁg zu kleineren oder größeren Anpassungen

innerhalb der Stammorganisation. Denn meistens sind auch irgendwelche betrieblichen

Prozesse von der Neuerung betroffen. Beispiele: Neue Produkte kommen dazu. Einzelne

Arbeitsschritte verändern sich. Es ergibt sich eine neue Betriebsstruktur: Organisations-

einheiten werden neu zusammengestellt. Bisherige Arbeiten fallen weg. Dienstleistungen

werden neu deﬁniert. Diese Veränderungen bedingen immer Anpassungen für die betei-

ligten Personen in ihren Tätigkeiten, ihrem Verhalten oder sogar in ihrer Haltung.

4.5.1

Change und Transformation

Eine Veränderung kann unterschiedliche Auslöser haben. Dargestellt an einem allgemei-

nen Businessmodell in Abb. 4.35 kann der Impuls zum Beispiel erfolgen aufgrund von

Veränderungen in der Strategie, Korrekturen und Anpassungen in den Strukturen und

Prozessen oder auch durch das Bedürfnis, die Organisationskultur weiterzuentwickeln.

Wo auch immer der initiale Impuls gesetzt wird, es hat eine Auswirkung auf die anderen

zwei Dimensionen des Businessmodells.

4.5

Veränderung und Widerstand

477

Kultur

Management

Strategie

Struktur

Abb. 4.35 Veränderung von Strategie, Struktur und Kultur

4.5.1.1

Change: Probleme lösen

Wir sprechen von „Change“, wenn die heutige Situation verändert werden muss: Pro-

zesse und Methoden müssen verbessert oder ersetzt werden, um den aktuellen oder zu-

künftigen Anforderungen zu genügen.

Beispiele

Die Produktionskosten sind zu hoch. Neue Produktionsprozesse müssen gefunden

werden, um die Kosten zu reduzieren. So wird ein höherer Deckungsbeitrag mög-

lich.

Die Aufwandschätzungen für die Projekte waren wiederholt 20 % zu tief. Die Re-

ferenzwerte der analogen Schätzmethode sollen überprüft werden. Zudem wird für

Projekte mit hohem Komplexitätsgrad der Planning Poker (Abschn. 2.4.6.2) einge-

führt.

4.5.1.2

Transformation: Lösungen finden

Von „Transformation“ sprechen wir, wenn aufgrund einer Vision oder von Zukunftsanfor-

derungen neue Strategien entwickelt werden sollen.

478

Team

Beispiele

Unsere Produkte sollen weitgehend mittels Roboter produziert werden können. Wel-

che Prozesse, Strukturen und Verfahren müssen genutzt werden, um weitgehend auf

Automation umstellen zu können?

In einer Organisation soll vermehrt nach dem agilen Ansatz gearbeitet werden. Es

wird ein Projekt zur Organisationsentwicklung gestartet, basierend auf dem Ansatz

von „Radical Collaboration“ (Abschn. 4.1.14.3). Damit ist die Grundlage zu legen

für die Selbststeuerung in den agilen Teams.

4.5.2

Mind Change

Veränderungen an Strategie und Struktur beeinﬂussen die Kultur

Das Businessmodell in Abb. 4.35 legt nahe, dass jede Veränderung in der Strategie oder in

der Struktur einen Einﬂuss hat auf die Kultur und damit auf den einzelnen Menschen und

die Organisation als Ganzes. In vielen Projekten erschließen sich Nutzen und Wirtschaft-

lichkeit erst, wenn die involvierten Personen ihr Verhalten anpassen, seien es innovative

technologische Lösungen, effektivere Prozesse oder neue Produkte.

Gezielte Projektaktivitäten und eine entsprechende Projektführung sind notwendig, da-

mit die Betroffenen ihr Verhalten verändern können. Dies ist umso mehr gefragt, als die

Veränderungszeiten immer kürzer werden. Die fortlaufenden koordinierten Maßnahmen

werden als Veränderungsmanagement bezeichnet. Es sind nicht nur die Change-Projekte,

die Veränderung mit sich bringen. Es betrifft alle Projekte in größerem oder kleinerem

Ausmaß.

Zwei Ebenen der Veränderung

Abb. 4.36 stellt die beiden Ebenen der Veränderung dar. Auf der Ebene der „hard factors“

werden im Change oder in der Transformation neue Strukturen, Prozesse oder Systeme

erarbeitet. Die Führung und Steuerung dieses physischen Prozesses wird als Management

und Controlling bezeichnet. Ebenso wichtig sind der psychische und geistige Wandel.

Hier stehen die „soft factors“ im Vordergrund, mit denen die Kultur, die Fähigkeiten und

das Verhalten der Individuen und der Organisation entwickelt werden. Für diesen Teil der

Projektleitung sind Leadership und Kommunikationskompetenzen gefordert.

4.5.3

Der Mensch und Veränderung

Haben Sie gerne Veränderung? Wie halten Sie es persönlich mit Veränderung in Ihrem pri-

vaten Leben? Die meisten von uns sind wohl nicht darauf aus, dass sich das Leben um sie

herum permanent verändert. Wieso ist das so? Zuerst einmal haben wir alles Wissen, alle

Abläufe und Fertigkeiten, die wir im Projektalltag brauchen, einmal mühsam gelernt. Sich

4.5

Veränderung und Widerstand

479

Umzusetzende

Vision

Strategie

Organisation

Veränderung

Physischer Wandel

wird gesteuert

durch:

– Management

– Controlling

hard factors

soft factors

Psychischer Wandel

wird gesteuert

durch:

– Leadership

– Kommunikation

Strukturen

Systeme

Prozesse

Kultur

Fähigkeiten

Verhalten

Erfolg

Change/Transformation

Sachlogik

Mind Change

Psychologik

Abb. 4.36 Zwei Ebenen der Veränderung

etwas Neues anzueignen ist ein anspruchsvoller Prozess, der uns viel Energie abverlangt.

Was wir einmal mit viel Aufwand kognitiv lernen müssen, wird dann über die Jahre zu un-

seren Routinen, zu unseren impliziten und intuitiven Verhaltensmustern. Diese Muster

abzurufen kostet uns wenig Energie. Sie sind verankert in festen neuronalen Netzwerken

in unserem Hirn (Abschn. 3.3.2). Da der Mensch den größten Teil seiner Evolution lernen

musste, in einer Welt des Mangels zu überleben (für viele ist das leider auch heute noch

der Fall), hat unser Hirn auch einen efﬁzienten „Stand-by“-Modus entwickelt: So versucht

unser Hirn stets, seinen Energieverbrauch so gering wie möglich zu halten.

Das Bekannte und Beständige hat noch weitere Vorteile für uns: Wir fühlen uns si-

cher. Als Projektverantwortliche haben wir uns über die Jahre viel Wissen und Erfahrung

angeeignet. Wir haben damit in der Organisation oder gar in der Branche eine Reputati-

on aufgebaut und ein wertvolles formales und informelles Netzwerk aufgebaut. Über all

das können wir, bewusst oder unbewusst, die individuell wichtigen persönlichen Grund-

bedürfnisse befriedigen (Abschn. 3.3.3).

Veränderungen in unseren Abläufen, Aufgaben oder Zuständigkeiten bedeuten für uns,

Sicherheits- und Identitätsstiftendes loszulassen. Je nach den Charaktereigenschaften

eines Menschen mit seinen Grundbedürfnissen und Kompetenzen oder seiner persönli-

chen Resilienz (Abschn. 3.8.4) wendet er eine unterschiedliche persönliche Bewältigungs-

480

Team

strategie an (Abschn. 3.5.4). Für viele bedeutet Veränderung auch Unsicherheit, manchmal

sogar Angst. Wer diese Unsicherheit oder Angst nicht überwinden kann, wird am Status

quo festhalten.

4.5.4

„Formel“ der Veränderung

Wer meint, dass sich die Veränderung von Menschen oder Organisationen über eine ein-

fache Formel herleiten lässt, reduziert diese auf ein triviales System (Abschn. 1.6.2).

Organisationen und Menschen sind viel komplexer. Trotzdem kann eine Formel als Er-

gänzung zur Veränderungsformel in Abschn. 1.4.4 herbeigezogen werden:

In der Veränderung stehen sich die Lernangst und die Existenzangst gegenüber. Lern-

angst meint, dass Menschen oder Organisationen es sich nicht zutrauen, in einem neuen

Thema wieder dieselbe Kompetenz aufbauen zu können. Diese „Kellerwanderung“ be-

deutet, temporär inkompetent zu werden oder gar seine Identität, den Status oder die

Gruppenmitgliedschaft zu verlieren. Die Existenzangst beinhaltet den Verlust der Exis-

tenzgrundlage: den Verlust der Marktposition oder sogar der Überlebensfähigkeit der

Organisation, das Auseinanderfallen eines Teams oder – auf der persönlichen Ebene –

den Verlust der Fachkompetenz, der Anstellung oder der eigenen Gesundheit.

Welche Angst ist in unserer Wahrnehmung stärker? Auch wenn es viele nicht gerne

hören wollen: Es ist die Lernangst. Die permanente Weiterentwicklung und das Weiterler-

nen von Organisationen und Menschen sind sehr anspruchsvoll, anstrengend und auch mit

vielen Unsicherheiten und Risiken verbunden. Bestehende Gewohnheitsmuster hingegen

vermitteln Sicherheit. In den meisten Organisationen braucht es sehr viel Energie, einen

nachhaltigen Veränderungsprozess zu durchlaufen. Veränderung hat einen hohen Preis

und verlangt ein erhebliches Commitment von allen involvierten Personen. Sie müssen

erst noch bereit sein, ein höheres Risiko zu tragen.

Beispiel

Der Mensch ist sehr gut im Verdrängen. Viele versuchen, das Leben so lange wie mög-

lich in den gewohnten Bahnen abzuwickeln, seien es Organisationen oder einzelne

Menschen. Diese vertrauten Bahnen werden erst dann verlassen, wenn es wirklich nicht

mehr geht: Jemand fürchtet, seine Anstellung zu verlieren, wenn er sich nicht mit einer

neuen Technologie vertraut macht. Oder er leidet so stark unter Stress, dass die psycho-

somatischen Symptome nicht mehr ignoriert werden können. Oder eine Organisation

befürchtet, aufgrund des Markteintritts eines Mitbewerbers einen Umsatzeinbruch zu

erleiden, wenn sie nicht einen Innovationsschub erzielen kann.

In diesen Situationen steigt die Existenzangst, oft begleitet von einem höheren Stress-

niveau. Die gesteigerte Existenzangst führt nun dazu, dass die Lernangst in den Hin-

tergrund tritt. Verdrängung ist keine Option mehr. Auf der persönlichen Ebene kann das

4.5

Veränderung und Widerstand

481

eigene Verhalten verändert werden, oder die Situation wird neu bewertet (Abschn. 3.5.4).

Organisationen stoßen die Veränderung über eine neue Strategie und/oder Struktur an.

4.5.5

Veränderungsbereitschaft in Organisationen

Menschen, die Veränderungen positiv konnotieren und sich ihnen neugierig und lustvoll

zuwenden, bilden die Ausnahme von der oben beschriebenen „Formel“ der Verände-

rung. Rogers unterscheidet in Veränderungsprozessen folgende Anwendergruppen (Ro-

gers 2003):

Innovatoren

Visionäres Denken, enthusiastisch, manchmal auch unkritische und einseitige Einstel-

lung gegenüber Neuerungen.

Frühe Übernehmer

Positive Haltung gegenüber Veränderungen unter Einbezug der Pros und Contras, des-

halb genießen sie hohe Akzeptanz in den Organisationen.

Frühe Mehrheit

Anfänglich indifferent gegenüber der Veränderung. Machen mit, allerdings ohne ho-

he Begeisterung. Lassen sich begeistern über schnelle Erfolge, die v. a. ihnen selbst

zugutekommen (Quick-Wins).

Späte Mehrheiten und Nachzügler

Diese ins Boot zu holen ist aufwändig, da sie eher resigniert oder mit aktivem Wider-

stand reagieren. Wenn die Gruppe zu groß ist, kann dies das Scheitern des Verände-

rungsprozesses bedeuten.

Die Abb. 4.37 stellt einerseits die prozentuale Verteilung der Personen auf die Gruppen

dar und zeigt auch auf, wann diese Gruppen in den Veränderungsprozess einsteigen. Was

bedeutet das für das Gestalten von Veränderungsprozessen?

Nach Rogers kann es auch zu viel Begeisterung geben für Veränderung (Innovatoren).

Der Wandel darf nie Selbstzweck sein. Er soll immer Mittel zum Zweck und auf spezi-

ﬁsche Ziele ausgerichtet sein. Auch soll er bezüglich der Risiken und der personellen und

ﬁnanziellen Ressourcen, die damit absorbiert werden, sorgfältig abgewogen sein.

Es ist eine Binsenwahrheit, dass sich nie alle involvierten Personen begeistert auf eine

Veränderung einlassen. Veränderung wird immer auch Widerstand generieren. Die späte

Mehrheit will zuerst Resultate sehen, bevor sie den Veränderungsprozess unterstützt. Um

sie zu gewinnen, müssen die durch die Veränderung erzielten Erfolge quantiﬁziert wer-

den. Die Nachzügler bleiben skeptisch. Dieser Gruppe darf nicht zu viel Aufmerksamkeit

geschenkt werden.

482

Team

Zeit

Nachzügler

16%

Frühe

Über-

nehmer

13.5%

Frühe

Mehrheit

34%

Späte

Mehrheit

34%

Anzahl Übernehmer

Innova-

toren

2.5%

Abb. 4.37 Verteilung der Anwendergruppen. (Rogers 2003)

Tab. 4.21 Sachlogik und Psychologik in Projekten

Sachlogik

Psychologik

Scope/Ziel und Anforderungen

Umgang mit Macht und Führung

Strategien

Bewältigung von Konﬂikten und Widerstand

Meilensteine und Sprint-Ziele

Entwicklung der Organisationskultur

Kosten und Ressourcen

Motivation und Sinn

Projektpriorität (Projektportfolio)

Persönliche Kommunikation

Projektplanung und -Abwicklung

Teamentwicklung

Projektorganisation

Wahrnehmung und Bewusstsein

Problemlösungsmethodik

Entwickeln von Fähigkeiten und Haltung

4.5.6

Psychologik und Sachlogik in Projekten

Zu der in Abb. 4.36 dargestellten Differenzierung der Veränderung auf den zwei Ebenen

Sachlogik (Change oder Transformation) und Psychologik (Mind Change) stellt Tab. 4.21

ein paar Schwerpunkte und Kompetenzbereiche gegenüber.

4.5

Veränderung und Widerstand

483

stark

schwach

Ohne glaubwürdige,

breite Veränderungs-

arbeit bewegt sich

wenig

Gestaltungswille der Führung

Kooperationsbereitschaft der Mitarbeiter

hohe

Konﬂiktdynamik

Misserfolg

vorprogrammiert

hohe

Veränderungsdynamik

begrenzte

Veränderungsreichweite

Abb. 4.38 Gestaltungswille und Kooperationsbereitschaft

4.5.7

Gestaltungswille und Kooperationsbereitschaft

Wesentliche Voraussetzungen für getragene und greifende Veränderungen sind die volle

Identiﬁkation und das Commitment der Geschäftsleitung. Viele Veränderungsvorhaben

scheitern, weil dieses Commitment von oben fehlt und die Notwendigkeit der Verände-

rungen nicht immer wieder kommuniziert und bestätigt wird. Wenn sich das Management

aktiv am Veränderungsprozess beteiligt, lebt es den gemeinsamen Lernprozess vor. Die

von der Organisation angestrebten Veränderungen werden dadurch (eher) übernommen.

Die Abb. 4.38 stellt dar, dass die Veränderungsdynamik am höchsten ist, wenn ein

hoher Gestaltungswille in der Führungsorganisation mit einer starken Kooperationsbereit-

schaft der Mitarbeiter gepaart werden kann.

Ist der Gestaltungswille stark, die Kooperationsbereitschaft schwach, muss mit einer

hohen Konﬂiktdynamik in der Projektabwicklung gerechnet werden. Nur die Mitarbei-

ter ohne Unterstützung der Führung können wenig erreichen. Wenn beide Seiten wenig

Engagement zeigen, ist der Misserfolg vorprogrammiert.

484

Team

Vorhandenes

Gleichgewicht

«Soziale Systeme»

neigen dazu, den

Status quo

möglichst lange

zu erhalten.

Etwas Neues

einführen

Das Neue integrieren

Sobald sich erste

Erfolge der Verände-

rung abzuzeichnen

beginnen, gewinnt das

Neue an Attraktivität.

Neues Gleichgewicht

Verwirrung Unsicherheit

Chaos und Chance

Nur das positive Durchleben

dieser Phase führt zu einer

echten Veränderung.

Abb. 4.39 Zustände in Veränderungsprozessen. (Satir et al. 1995)

4.5.8

Veränderungsprozess-Modell

4.5.8.1

Phasen der Veränderung

Virginia Satir hat ihr Modell „Phasen der Veränderung“ ursprünglich für die Familienthe-

rapie entwickelt. Das Modell beschreibt auch die Entwicklung von Menschen, Gruppen

und Organisationen im Umgang mit Veränderung über fünf Phasen (Abb. 4.39). Diese

werden mit unterschiedlicher Bereitschaft und mit unterschiedlichem Zeitbedarf durch-

laufen.

Phase 1: Status quo oder Gleichgewicht

Diese Phase (meist die Ausgangslage) des stabilen Gleichgewichts und der Kontinuität

vermittelt Sicherheit. Die eingespielte Routine gibt das Gefühl, efﬁzient zu sein. Um die-

ses Gleichgewicht nicht zu gefährden, wird ein Veränderungsbedarf in der Praxis häuﬁg

möglichst lange ausgeblendet, indem die Realität nicht wahrgenommen werden kann oder

will. Je länger diese Phase dauert, umso schwieriger wird es für die Betroffenen, sich auf

Veränderungen einzulassen.

4.5

Veränderung und Widerstand

485

Phase 2: Aufbruch, etwas Neues

In dieser Phase wächst das Bewusstsein, dass Veränderungen notwendig werden. Meist

ist es nur ein kleiner Kreis – z. B. das Management –, der aufgrund des Veränderungsbe-

darfs etwas Neues plant und in die Wege leitet. Die Bereitschaft zur Veränderung ist in

dieser „Auftauphase“ herzustellen.

Phase 3: Verwirrung, Unsicherheit, Chaos und Chance

Bei der Einführung des Neuen entsteht anfangs Verwirrung. Häuﬁg nehmen die Mitar-

beiter den Veränderungsprozess erst in dieser Phase wahr. Sie müssen auf einen bereits

fahrenden Zug aufspringen und versuchen dann mit mehr oder weniger Bereitschaft, die

Veränderung zu bewältigen und das Neue auszuprobieren. Meist geschieht dies mit den

bisherigen Methoden und Verhaltensweisen, die für die neuen Anforderungen kaum mehr

geeignet sind. Im Alltag entstehen Situationen, in denen nichts mehr funktioniert, da das

Bewährte nicht mehr gilt und das Neue noch ungewohnt oder unbekannt ist.

In der Folge entsteht ein Chaos, sowohl für die Menschen als auch für die ganze Or-

ganisation. Nur das positive Durchleben dieser Phase führt zu einer echten Veränderung!

Allerdings darf diese Phase nicht zu lange dauern, denn sie ist mit viel Angst, Unsicher-

heit und teuren Reibungsverlusten verbunden. Oft ist nicht klar, ob jetzt noch das Alte

oder bereits das Neue gilt.

Phase 4: Integration

Die Fähigkeit der Menschen, Phasen der Verwirrung und der Krise trotz aller Schwie-

rigkeiten positiv anzugehen, ist ein Schlüsselfaktor für das Erreichen der Phase 4. Sobald

sich erste Erfolge der Veränderung abzeichnen, gewinnt das Neue an Attraktivität. Es

kommt zu einer Integrationsphase, in der die neue Wirklichkeit eingeübt und die neu-

en Verhaltensweisen erprobt werden, bis allmählich wieder Sicherheit entsteht. Der neue

Zustand wird wieder „eingefroren“. Auch Fehler gehören zum Lernprozess. Diese sol-

len festgehalten und reﬂektiert werden, brauchen aber nicht gleich zu Kurskorrekturen zu

führen. Gelingt dieser tolerante Umgang mit Fehlern den Führungspersonen nicht, erfolgt

statt des Fortschritts ein Rückfall in Phase 3.

Phase 5: Stabilität und Status quo

Auf die Integrationsphase folgt die Phase des neuen Gleichgewichts. Diese Phase der

Konsolidierung ist wichtig für die Vertiefung der Erfahrungen und die Verankerung der

neuen Kenntnisse und Fähigkeiten. In der VUKA-Welt (Abschn. 3.3.4) werden diese Pha-

sen immer kürzer, weil sie von weiteren Veränderungen eingeholt bzw. überholt werden.

Die fünf Phasen werden nicht linear durchlaufen. Bei jeder größeren Schwierigkeit

gibt es Rückfälle in die Chaosphase. Angst und Resignation gewinnen die Oberhand. Mit

der Zeit nehmen aber sowohl die Anzahl als auch die Dauer dieser Rückfälle ab. Der

Veränderungsprozess beginnt zu greifen.

486

Team

Mitarbeiter

Führungskräfte

Oberste Leitung

Zeit

Die oberste Leitung ist

vor allen anderen in

die Veränderung involviert.

Darum bewegen sie sich

als Erste durch die

Veränderungskurve.

Danach werden

die Führungskräfte

informiert und

sie beginnen sich

durch die Kurve

zu bewegen.

Wenn die Mitarbeiter

informiert werden, sind die

Leitung und die Führungs-

kräfte bereits in der Inter-

grationsphase und können

den Mitarbeiter gegenüber

ungeduldig sein.

Abb. 4.40 Ungleichzeitigkeit von Veränderungsphasen

4.5.8.2

Ungleichzeitigkeit

Die Veränderungsphasen laufen in der Organisation für bestimmte Gruppen zeitlich ver-

setzt ab (Abb. 4.40). Dies bedeutet, dass nicht alle beteiligten Personen bzw. Hierarchie-

stufen sich zur gleichen Zeit in der gleichen Phase beﬁnden. Das kann zu zusätzlicher

Dynamik im Projekt führen. Diese Ungleichzeitigkeit entsteht durch den Wissensvor-

sprung der Verantwortlichen. Sie haben sich schon über längere Zeit mit der Veränderung

befasst und sind im Prozess entsprechend weiter vorangeschritten. Nun erwarten sie mit

Ungeduld rasche Resultate und erhöhen mit dieser Forderung die Spannung bei den Mit-

arbeitern.

Diese Ungleichzeitigkeit stellt insbesondere an die Projektleitung hohe Anforderungen.

4.5.9

Umgang mit Widerstand

4.5.9.1

Positive und negative Konnotation

Es gibt keine Veränderung ohne Widerstand. Nicht das Auftreten von Widerständen,

sondern deren Ausbleiben muss Anlass zur Beunruhigung geben. Widerstand darf weder

nur negativ konnotiert sein noch darauf reduziert werden, dass Verweigerer, Konservative

4.5

Veränderung und Widerstand

487

Ohne Veränderung

bleibt die menschliche

Entwicklung stehen.

Dauerhafte Veränderung ohne

Widerstand führt zu Willkür,

Chaos und Auﬂösung.

Jeder Mensch hat nur eine

eingeschränkte Kapazität

für Veränderung.

Keine Veränderung

ohne Widerstand

• Kein Widerstand ist ein Grund

zur Besorgnis

Nichtbeachten von Widerstand

führt zu Blockierungen

• Es ist ein faires Angebot,

wenn man versucht eine Lösung

mittels anderer Ansätze zu

ﬁnden

Die Kunst Widerstand zu bewältigen

• Mit dem Widerstand gehen,

nicht dagegen

• Gründe ausführen, Dialoge führen

• Vorgehensplan zusammen

abgleichen

Widerstand enthält eine

verschlüsselte Botschaft

• Denkpausen einlegen

• Meinungen neu beurteilen

Abb. 4.41 Aspekte von Widerstand und Veränderung

oder Ewiggestrige sich gegen den Wandel der Zeit stemmen. Widerstand ist ein wichtiges

Potenzial, wenn Menschen etwas, was für sie wertvoll ist, schützen wollen.

Wenn ein Projekt etwas verändert, das Sie persönlich als wertvoll und schützenswert

erachten, leisten auch Sie selber Widerstand. Wenn Veränderungsprozesse auf keinen

Widerstand stoßen, ist offenbar nichts Schützenswertes (mehr) vorhanden. Oder die be-

troffenen Stakeholder sind schon in der Resignation oder inneren Kündigung.

Abb. 4.41 fasst positive und negative Aspekte von Widerstand und Veränderung zu-

sammen.

Veränderung bedeutet Aufbruch und beinhaltet die Chance, sich weiterzuentwickeln.

Es heißt aber auch loszulassen, von Liebgewordenem Abschied zu nehmen. Widerstand

nicht zu beachten führt zu Blockaden. Sozialer Druck führt zu Gegendruck. Jeder sorgfäl-

tig behandelte Widerstand (siehe auch Abschn. 3.5.4 Konﬂikt) kann neue Ressourcen und

Fähigkeiten hervorbringen. Wie das geht?

Beteiligte und Betroffene einbeziehen, Feedbackschleifen einbauen

Transparenz und Offenheit als wesentliche Grundhaltung

Nachteile mitkommunizieren

Vorteile und langfristigen Nutzen verständlich machen

Mitarbeiter sorgfältig auf neue Situationen vorbereiten und befähigen

488

Team

Widerstand

gegen

Veränderungen

Vorgetäuschte Inkompetenz

«Ich versteh‘ das nicht, was wir

da vorhaben!»

Resignation

«Es hat sowieso keinen Sinn!»

Gesundbeten

«Wir haben keine Probleme!»

Zeitmangel

«Ich muss Umsatz machen, ich

habe dafür keine Zeit!»

Passiver Widerstand

«Ich mache nur mehr das, was

man mir sagt. Die werden schon

sehen, was dabei herauskommt!»

Aktiver Widerstand

«Bei uns gehen die Uhren anders!»

Vorgetäuschtes Engagement

«Ich arbeite doch sowieso mit

voller Kraft im Projekt mit!»

Stellvertreter-Kriege

«Andere haben doch gar keine

Ahnung von unseren Problemen!»

Qualität

«Ich bin der Beste! Warum soll

ich mich ändern?»

Abb. 4.42 Formen von Widerstand

4.5.9.2

Ist Widerstand ein Synonym für Konflikt?

Wenn eine Person Widerstand leistet, bedeutet das in jedem Fall einen Konﬂikt? Wider-

stand wird oft als Synonym für Konﬂikt gebraucht (Kreyenberg 2005, S. 97). In unserem

Verständnis ist der Widerstand, wenn dieser in einer ersten Form auftritt, noch kein Kon-

ﬂikt. Es kann aber ein Konﬂikt daraus entstehen, wenn eine Partei auf ihrer Position

beharrt und dies dazu führt, dass sich eine andere Partei im eigenen Handeln beeinträchtigt

fühlt.

4.5.9.3

Formen von Widerstand

Widerstand enthält immer auch eine verschlüsselte Botschaft. Die Ursachen liegen häuﬁg

im emotionalen Bereich. Der Widerstand einer von Veränderung betroffenen Person kann

sich in sehr unterschiedlicher Form zeigen. Eine bestehende Ordnung, Struktur, Beziehung

oder anderes werden infrage gestellt. Dies bedroht das innere Gleichgewicht, was zu einer

Abwehrhaltung führen kann.

In Abb. 4.42 werden unterschiedliche Formen von Widerstand aufgeführt. Gleichgül-

tig, welche Form der Widerstand annimmt, letztlich sind die Ursachen verborgen in

individuellen oder sozialen Bedürfnissen. Widerstand enthält meist ein Energiepotenzi-

al, das konstruktiv genutzt werden kann.

4.5

Veränderung und Widerstand

489

Wie kann die Projektleitung mit Widerstand umgehen? Die Projektmitarbeiter oder

andere betroffene Personen sind eher bereit sich zu verändern, wenn . . .

die Veränderung als Chance und nicht als Bedrohung wahrgenommen und gelebt wird;

ein gutes Vertrauensverhältnis und eine offene Kommunikation gepﬂegt werden;

sie sich sicher fühlen, d. h. nicht mit Sanktionen und Machtübergriffen rechnen müssen,

wenn sie allfällige Missstände aufdecken bzw. ansprechen;

die Veränderungen für sie sinnvoll sind und für sie etwas Positives daraus resultiert;

ihre bisherigen Leistungen anerkannt werden;

sie frühzeitig in den Veränderungsprozess mit einbezogen werden;

sie gut informiert sind und die nötige Unterstützung erhalten;

auf ihren Widerstand eingegangen wird (wenn die „unterschwellige emotionale Ener-

gie“ ernst genommen wird, kann sie sinnvoll kanalisiert werden).

Sie sind eher weniger bereit, die Veränderungen aktiv mitzugestalten, wenn . . .

Angst und Unsicherheit das Arbeitsklima überschatten;

sich Handlungsmuster automatisiert haben;

Ignoranz oder Nichtbeachtung vorherrscht;

fehlendes Problembewusstsein, Verständnis und Isolation vorhanden sind;

im Team nicht offen kommuniziert wird;

kein Sinn erkennbar ist.

4.5.9.4

Umgang mit Widerstand

In den Gesprächen zur Klärung des Widerstandes ist vor allem darauf zu achten, dass

nicht um Positionen verhandelt wird. Die wahren Interessen des Widerstandes sind auf-

zudecken. Diese zeigen sich meist nicht offensichtlich und müssen stufenweise herausge-

arbeitet werden. Dazu empfehlen wir Autoren Ihnen ein Vorgehen in drei Stufen gemäß

Abb. 4.43, seien Sie Projektverantwortlicher, Coach oder neutrale Drittperson.

Stufe 1

Gehen Sie von sachlichen Bedenken als Ursache für den Widerstand aus. Fragen Sie

nach, was Ihr Gegenüber verstanden hat. Dann informieren Sie, um die Sachverhalte auf-

zuklären.

Handelt es sich tatsächlich um sachliche Bedenken, klären Sie sie inhaltlich, wägen

Sie die Argumente ab. Sind die Argumente jedoch vorgeschoben, weil dem Widerstand

andere Ursachen zu Grunde liegen, wird sich die Diskussion im Kreis der Schein-Sach-

lichkeit drehen. Gehen Sie zu Stufe 2, um den intellektuellen Schlagaustausch hinter sich

zu lassen.

Stufe 2

Man nimmt an, dass weit mehr als die Hälfte aller Widerstände auf Ängste zurückgehen.

Wenn Sie von Ängsten ausgehen müssen, wechseln Sie die Gesprächsstrategie: zuhören

490

Team

Ursache von Widerstand

Umgang mit Widerstand

Stufe 1:

Sachliche Bedenken

informieren
argumentieren
aufklären

Stufe 2:

Ängste und Befürchtungen

verstehen statt erklären
zuhören statt argumentieren
nachfragen und spiegeln

Stufe 3:

Eigeninteressen

klare Ansprache und Kompromiss
Konfrontation und Einlenken
Klärung über die Hierarchie

Ursache von Widerstand

Umgang mit Widerstand

Stufe 1:

Sachliche Bedenken

informieren
argumentieren
aufklären

Stufe 2:

Ängste und Befürchtungen

verstehen statt erklären
zuhören statt argumentieren
nachfragen und spiegeln

Stufe 3:

Eigeninteressen

klare Ansprache und Kompromiss
Konfrontation und Einlenken
Klärung über die Hierarchie

Abb. 4.43 Ursachen und Umgang mit Widerstand

statt argumentieren, verstehen statt erklären. Jetzt helfen Fragetechniken. Für Ihren Ge-

sprächspartner entsteht ein Raum, in dem er sich sicher fühlt. Auf der Basis von Vertrauen

können Sie Ängste ansprechen (Abschn. 4.4.10.3). Fragen Sie nach. Vergewissern Sie

sich, ob Sie Ihr Gegenüber richtig verstanden haben, indem Sie seine Aussagen mit ei-

genen Worten wiedergeben. Paraphrasieren Sie und hören Sie aktiv zu (Abschn. 3.9.8.2).

Erst wenn Ihr Gegenüber den Eindruck hat, dass Sie seine Ängste oder Befürchtungen

verstanden haben und Sie diese ernst nehmen, ist es möglich, gemeinsam nach Lösungen

zu suchen. Fragen Sie die Person, was ihr helfen könnte und was sie noch braucht, statt zu

früh schnelle Lösungen anzubieten.

Die sicherste Methode, nichts über die Ängste und Befürchtungen zu erfahren und

sich dabei eine Chance zu vergeben, ist das Beruhigen, Trösten, Beschwichtigen oder die

sachliche Erklärung, dass es doch „überhaupt keinen Grund gibt, sich Sorgen zu machen“.

Liegen dem Widerstand tatsächlich Ängste zugrunde, wird die Person auf das einfühl-

same Vorgehen reagieren und mit Ihnen nach praktikablen Wegen suchen.

Führen selbst mehrere solche Gespräche nicht weiter, liegen dem Widerstand vermut-

lich nicht Ängste zugrunde. Gehen Sie auf die dritte Stufe.

4.5

Veränderung und Widerstand

491

Stufe 3

Auf der tiefsten Stufe verursachen Eigeninteressen den Widerstand. Bilden Sie vor dem

Gespräch Hypothesen zu den Interessen und Antreibern dieser Person: Welche Begüns-

tigungen könnte sie verlieren, welche mühsam erworbenen Rechte oder Vorteile, welche

Incentives, welchen Status oder welches Prestige? Oder: Welche Vorteile und Freiheiten

bezüglich Arbeitszeit oder Fahrgemeinschaften?

Steigen Sie in dieses Gespräch ein, indem Sie diese Interessen klar ansprechen: Wel-

che Vorteile oder Privilegien könnte die Person durch die Veränderungen möglicherweise

verlieren oder aufgeben müssen?

Sie können nicht davon ausgehen, dass jede Person offen darüber spricht und bereit ist,

eine Lösung auszuhandeln. Wenn die Bereitschaft zum Gespräch fehlt, ist manchmal eine

klare Konfrontation notwendig. Im bilateralen Gespräch muss die Person auf ihr egois-

tisches Verhalten hingewiesen und dafür sensibilisiert werden, dass sie damit wichtige

Veränderungen behindert. Dann führt oft nur ein Machtentscheid der Hierarchie zur Lö-

sung der Situation. Selbst hier ist sorgfältiges Vorgehen geboten. Geben Sie der Person

die Chance, einzulenken und zur Kooperation zurückzukehren, bevor Sie den Weg über

die Hierarchie beschreiten. Insbesondere dann, wenn Sie nach der Veränderung mit dieser

Person zusammenarbeiten wollen oder müssen.

Tab. 4.22 Interventionen bei Widerstand

– Informationen sammeln

– Die besten Alternativen für sich selbst eruieren

– Die besten Alternativen der Gegenpartei erkennen

– Optionen für den beidseitigen Vorteil entwickeln

– Objektive Kriterien formulieren

– Mögliche Verhandlungslösungen evaluieren

Informieren über:

– Ist-Situation: wertfrei

– geplante Veränderungen und Ziele: rechtzei-

tig und transparent

– Konsequenzen für die Mitarbeiter: umfassend

und kontinuierlich

Hinhören/Hinschauen auf:

– Äußerungen der Mitarbeiter

– außergewöhnliches Verhalten

– Gerüchte usw.

– verschiedene Formen von Widerstand

Beteiligen an:

– Diskussionsveranstaltungen

– Bewertung der Ist-Situation

– Entscheidungsprozessen

– Hearings und Präsentationen

Eingehen auf:

– Bedürfnisse der Betroffenen

– Wünsche und Meinungen

– Gute Ideen

– Härtefälle

Verhandeln über:

– Streitpunkte

– Meinungsverschiedenheiten: in kooperativer

und konsensfähiger Weise

Training und Ausbildung:

– so früh wie möglich

– je nach Bedarf, sowohl bei Inhalten auf der

Sachebene als auch auf der Beziehungsebene

492

Team

Abschließende Überlegungen zu den drei Stufen

In dieser Reihenfolge vorzugehen empﬁehlt sich, da Sie damit keinen „Schaden“ anrich-

ten. Unterstellt man jemandem, der sachliche Bedenken hat, er hätte Ängste, könnte er

sich nicht richtig ernst genommen fühlen. Einer Person mit Ängsten zu unterstellen, sie

hätte Eigeninteressen, führt häuﬁg zu einer Kränkung und macht es unmöglich, über die

Ängste zu sprechen.

4.5.9.5

Interventionen bei Widerstand

Tab. 4.22 fasst mögliche Interventionen bei Widerstand zusammen.

Wenn Teammitglieder Widerstand signalisieren, erwarten sie, dass er wahrgenommen

und aufgearbeitet wird. Schenkt die Projektleitung dem Widerstand keine Beachtung,

fühlen sich die Teammitglieder unterlegen, verletzt oder nicht ernst genommen. Ihr Miss-

behagen und ihre Unzufriedenheit nehmen zu. Sie ziehen sich zurück und verhalten sich

passiv. Die negativen Emotionen werden auf andere projiziert. Der Widerstand wird perso-

nalisiert. Es kann sich daraus ein sozialer Konﬂikt mit einer großen Dynamik entwickeln

wie „Die Projektleitung trägt die Schuld, dass . . . !“.

4.6

Zum Schluss ...

Es gibt nichts Gutes, außer man tut es (Erich Kästner).

Noch vor Kurzem genügte es, über die nötige Methodenkompetenz zu verfügen, um

Projekte abzuwickeln. So wurden oftmals die bestens ausgewiesenen Fachkräfte zu Pro-

jektleitern ernannt. Im vorliegenden Handbuch Projektmanagement zeigen wir Autoren

auf, dass für den Erfolg von komplexen, interdisziplinären Vorhaben unterschiedliche

Kompetenzen nötig sind. Deshalb haben wir die methodischen Grundlagen in einen Bezug

gestellt zum Menschen, der in Projektteams wirkt. Die drei Ebenen sind in einer Wechsel-

wirkung miteinander verknüpft.

Wir hoffen, dass Sie daraus immer wieder neue, konstruktive Impulse ableiten kön-

nen, um die Herausforderungen in Ihrer Projektarbeit konstruktiv zu bewältigen. Projekte

schaffen Veränderung. Das fordert alle Beteiligten immer wieder heraus. So werden auch

Sie selber immer wieder – im Sinne von Erich Kästner – gefordert und eingeladen sein,

für Ihre Projekte Gutes zu tun.

Literatur

Alter, U. (2008). Informieren als Führungsaufgabe. In: Steiger, T. und Lippmann, E. (Hrsg).

Handbuch angewandte Psychologie für Führungskräfte (Bd. II). Heidelberg: Springer Medizin

Verlag.

Baer André (2018). Unveröffentlichte Seminarmanuskripte

Literatur

493

Ballreich, R., & Hüther, G. (2009). Du gehst mir auf die Nerven! Neurobiologische Aspekte der

Konﬂiktberatung. Stuttgart: Concadora Verlag.

Berkel, K. (2014). Konﬂikttraining. Hamburg: Windmühle Verlag GmbH.

Blanchard, J. H. (2015). Management of Organizational Behavior. Chennai: Pearson India.

Dobelli, R. (2017). Die Kunst des guten Lebens. München: Piper Verlag.

Euforia. From Inspiration to Impact. https://www.euforia.org

Fisher, R., Ury, W., & Patton, B. (1999). Das Harvard-Konzept. Frankfurt / New York: Campus

Verlag.

French, J. Jr., & Raven, B. (1959). The Bases of Social Power. In: D. Cartwright (Hrsg.), Studies in

social power (S. 150–167). Oxford, England: University of Michigan.

Gellert, M., & Nowak, C. (2007). Teamarbeit – Teamentwicklung – Teamberatung (3. Auﬂage

Ausg.). Meezen: Limmer Verlag.

Glasl, F. (2004). Konﬂiktmanagement. Ein Handbuch für Führungskräfte (8. Auﬂage.). Bern: Haupt

Verlag.

Glasl, F. (2008). Selbsthilfe in Konﬂikten. Bern: Haupt Verlag.

Hüther, G. (2016, 2001, 12. Auﬂage). Bedienungsanleitung für ein menschliches Gehirn. Göttingen:

Vandenhoeck & Ruprecht Verlag.

Hüther, G. (2016, 1997, 13. Auﬂage). Biologie der Angst. Wie aus Stress Gefühle werden. Göttin-

gen: Vandenhoeck & Ruprecht Verlag.

Klein, Peter & Limberg-Strohmaier, Sigrid (2012). Das Aufstellungsbuch – Familienaufstellung,

Organisationsaufstellung und neuste Entwicklungen. Wien: Braumüller Verlag.

Königswieser, R., & Hillebrand, M. (2004). Einführung in die systemische Organisationsberatung.

Heidelberg: Carl-Auer-Systeme Verlag.

Kreyenberg, J. (2005). Konﬂikt-Management. Berlin: Cornelsen Verlag.

Lippmann, E. (2008). Konﬂiktmanagement. In: T. Steiger & E. Lippmann (Hrsg.), Handbuch ange-

wandte Psychologie für Führungskräfte (Bd. II). Heidelberg: Springer Medizin Verlag.

Oestereich, B. und Schröder, C. (2017). Das kollegial geführte Unternehmen. München: Franz Vah-

len GmbH.

Radatz, S. (28. Januar 2009). Führen ohne „Führungsmacht“. ProjektMagazin.

Rogers, E. M. (2003). Diffusion of Innovations. New York: Free Press.

Rosselet, C. und Senoner, G. (2010). Management macht Sinn – Organisationsaufstellungen in Ma-

nagementkontexten. Heidelberg: Carl-Auer-Systeme Verlag.

Satir, V. et al. (1995). Das Satir-Modell. Paderborn: Junfermann Verlag.

Schmidt, E. R., & Berg, H. G. (2008). Beraten mit Kontakt. Frankfurt: Gabal Verlag.

Schwarz, G. (2014). Konﬂiktmanagement. Wiesbaden: Springer Gabler Verlag.

Seliger, R. (2008). Das Dschungelbuch der Führung (5. Auﬂage, 2014 Ausg.). Heidelberg: Carl-

Auer Verlag GmbH.

Spisak, M. und Della Picca, M. (2017). Führungsfaktor Psychologie. Berlin Heidelberg: Springer-

Verlag.

Steiger, T. und Lippmann, E. (Hrsg), (2008. 3. Auﬂage Ausg., Bd. I&II). Handbuch angewandte

Psychologie für Führungskräfte. Heidelberg: Springer Medizin Verlag.

Tamm, J. und Luyet, R. (2005). Radical Collaboration. New York: Harper Collins.

Wastian, M. et al. (2009). Angewandte Psychologie für Projektmanager. Heidelberg: Springer Me-

dizin Verlag.

Watzlawick, P. (2004). Anleitung zum Unglücklich sein. München: Piper Verlag.

Weber, G. (2016). Basics des Aufstellens von Organisationen und Arbeitsbeziehungen, Grundla-

gen und Vorgehensweisen. In: Weber, G. und Rosselet, C. (Hrsg.) Organisationsaufstellungen

– Grundlagen, Settings, Anwendungsfelder. Heidelberg: Carl-Auer-Systeme Verlag.

494

Team

Zaninelli, S. (2005). Chancen und Herausforderungen weltweiter Zusammenarbeit über die Entfer-

nung. In: Wissensmanagement in der IHK-Organisation, Geschäftsfeld International, 1/2005.

Lübeck.

Zirkler, M. (2008). Konzepte der Macht. In: Steiger, T. und Lippmann, E. (Hrsg). Handbuch ange-

wandte Psychologie für Führungskräfte (Bd. II). Heidelberg: Springer Medizin Verlag.

Referenzliste zur Individual Competence Baseline

(ICB) der IPMA

Abschn. 1.8 beschreibt die Standards und Zertiﬁzierungsmodelle im Projektmanagement.

Das vorliegende Handbuch Projektmanagement deckt wie die IPMA die verschiedenen

notwendigen Kompetenzen für das Projektmanagement ab und ist nicht auf ein deﬁniertes

prozessorientiertes Framework ausgelegt.

Die Basis für die IPMA-Zertiﬁzierung bildet die Individual Competence Baseline

(ICB). Die notwendigen Kompetenzen strukturiert IPMA anhand des „Eye of Compe-

tence“ (siehe Abb. 5.1).

Folgende Referenzierung Tab. 5.1 zwischen der Swiss Individual Competence Baseline

(Version 4.0) für Projektmanagement und dem vorliegenden Handbuch Projektmanage-

ment unterstützt Personen, welche eine IPMA-Zertiﬁzierung anstreben.

Die Referenzierung kann auch sinngemäß für die beiden Swiss ICB für Programm-

management und Portfoliomanagement angewendet werden. Die Adaptierung an das Pro-

grammmanagement und das Portfoliomanagement muss jedoch durch den Leser vorge-

nommen werden.

495

J. Kuster et al., Handbuch Projektmanagement, https://doi.org/10.1007/978-3-662-57878-0_5

496

Referenzliste zur Individual Competence Baseline (ICB) der IPMA

People

Practice

Perspective

Practice

Abb. 5.1 Eye of Competence von IPMA (International Projectmanagement Association)

Referenzliste zur Individual Competence Baseline (ICB) der IPMA

497

Tab. 5.1 Swiss Individual Competence Baseline (ICB) Version 4.0

Kompetenz

Kompetenzindikatoren

Abschnitt im Buch

Kompetenzbereich Kontext (Perspective)

1.01 Strategie

1.01.01 Das Projekt mit der Mission und der

Vision der Organisation in Einklang bringen

1.2.5/2.2.2/2.2.3/2.3.1/

2.3.2/2.7.1

1.01.02 Chancen identiﬁzieren und ausschöpfen,

die die Strategie der Organisation beeinﬂussen

1.2.5/2.2.2/2.2.3/2.3.8

1.01.03 Rechtfertigung für das Projekt

entwickeln und sicherstellen, dass die betriebs-

wirtschaftlichen und/oder organisationalen

Gründe, die zum Projekt geführt haben, weiterhin

bestehen

2.2.2/2.2.4/2.3.2/2.3.9/

2.3.11/2.3.12/2.5.4/2.5.6/

2.5.7/2.7.1

1.01.04 Kritische Erfolgsfaktoren bestimmen,

beurteilen und überprüfen

2.3.1

1.01.05 Key Performance Indicators (KPI) be-

stimmen, beurteilen und überprüfen

2.3.1

1.02.01 Die Grundlagen des Projektmanagements

und dessen Einführung kennen

1.1–1.4/2.1/2.3.9

1.02.02 Die Grundlagen des Programmmanage-

ments und deren Einführung kennen

1.9/2.7.2

1.02.03 Die Grundlagen des Portfoliomanage-

ments und dessen Einführung kennen

1.2.3/1.2.4/1.9/2.7.1/3.9

1.02.04 Das Projekt mit den Supportfunktionen

in Einklang bringen

2.7.3/2.7.4

1.02.05 Das Projekt mit den Entscheidungs- und

Berichterstattungsstrukturen sowie den Quali-

tätsanforderungen der Organisation in Einklang

bringen

2.3.5/2.3.6/2.4.11/2.5.6/

4.1.4

1.02.06 Das Projekt mit den Prozessen und Funk-

tionen der HR in Einklang bringen

2.3.5/2.3.9/2.6.4/3.5/

3.10/4.1.4

1.02 Governance,

Strukturen und

Prozesse

1.02.07 Das Projekt mit den Finanz- und Control-

ling-Prozessen in Einklang bringen

2.3.5/2.5.6/2.5.7/4.1.4

498

Referenzliste zur Individual Competence Baseline (ICB) der IPMA

Tab. 5.1 (Fortsetzung)

Kompetenz

Kompetenzindikatoren

Abschnitt im Buch

1.03.01 Die für das Projekt gültigen Rechtsvor-

schriften identiﬁzieren und einhalten

2.3.3.2/2.3.8/2.3.10.4/

2.3.10.5/2.9

1.03.02 Alle für das Projekt relevanten Vorschrif-

ten für Sicherheit, Gesundheit und Umweltschutz

(SGU) identiﬁzieren und einhalten

2.3.3.2/2.3.8/2.3.10.4/

2.3.10.5

1.03.03 Alle für das Projekt relevanten Verhal-

tensregeln und Berufsvorschriften identiﬁzieren

und einhalten

2.3.3.2/2.3.10.4/3.2

1.03.04 Für das Projekt relevante Prinzipien und

Ziele der Nachhaltigkeit identiﬁzieren und ein-

halten

2.3.2/2.3.3.2

1.03.05 Für das Projekt relevante professionelle

Standards und Tools bewerten, nutzen und wei-

terentwickeln

1.4/1.8/2.3.10.4/2.7.1.1/

2.7.1.2/2.7.3./2.7.4

1.03 Compliance,

Standards und

Regulationen

1.03.06 Die Projektmanagementkompetenz der

Organisation bewerten, vergleichen und verbes-

sern

1.8/2.7.3/3.10

1.04 Macht und

Interessen

1.04.01 Persönliche Ambitionen und Interessen

Dritter und deren potenzielle Auswirkungen auf

das Projekt beurteilen sowie diese Kenntnisse

zum Nutzen des Projekts verwenden

2.3.5/2.3.10.1/4.1.3/4.5

1.04.02 Informellen Einﬂuss von Einzelpersonen

und Personengruppen und deren potenzielle Aus-

wirkungen auf das Projekt beurteilen sowie diese

Kenntnisse zum Nutzen des Projekts verwenden

2.3.5/2.3.9/4.1.3/

4.2.2/4.5

1.04.03 Persönlichkeiten und Arbeitsstile Dritter

beurteilen und zum Nutzen des Projekts einset-

zen

3.1/3.2/3.4/3.10.2/

4.1.14.1/4.1.14.2

1.05 Kultur und

Werte

1.05.01 Kultur und Werte der Gesellschaft und

deren Auswirkungen auf das Projekt beurteilen

1.6/2.3.5/2.3.10.1/3.4/

4.1/4.2

1.05.02 Das Projekt mit der formellen Kultur und

den Werten der Organisation in Einklang bringen

2.3.5/2.3.10.1/2.3.10.4/

3.4/4.1/4.2

1.05.03 Die Informelle Kultur und Werte der

Organisation und deren Auswirkungen auf das

Projekt beurteilen

2.3.5/2.3.10.1/3.4/4.1/4.2

Referenzliste zur Individual Competence Baseline (ICB) der IPMA

499

Tab. 5.1 (Fortsetzung)

Kompetenz

Kompetenzindikatoren

Abschnitt im Buch

Kompetenzbereich Menschen (People)

2.01.01 Einﬂuss der eigenen Werte und persön-

lichen Erfahrungen auf die Arbeit identiﬁzieren

und reﬂektieren

3.3/3.4/3.8.1/3.9/3.10

2.01.02 Selbstvertrauen auf der Basis von persön-

lichen Stärken und Schwächen aufbauen

3.5/3.8.2/3.10

2.01.03 Persönliche Motivationen identiﬁzieren

und reﬂektieren, um persönliche Ziele zu setzen

und darauf zu fokussieren

3.3.3/3.5/3.7/3.8/3.10

2.01.04 Eigene Arbeit abhängig von der Situation

und den eigenen Ressourcen organisieren

3.2/3.5/3.8/3.9/3.10.2/

2.01

Selbstreﬂexion

und Selbst-

management

2.01.05 Verantwortung für das persönliche Ler-

nen und die persönliche Weiterentwicklung

übernehmen

3.8/3.10

2.02.01 Ethische Werte bei allen Entscheidungen

und Handlungen anerkennen und anwenden

3.4/3.9/4.4.11.8

2.02.02 Die Nachhaltigkeit von Leistungen und

Ergebnissen fördern

2.3.4/2.6.5/3.8.4/4.3.3/

4.5.4

2.02.03 Verantwortung für die eigenen Entschei-

dungen und Handlungen übernehmen

2.8.2/3.8.4/3.10/4.1.5/

4.1.6

2.02.04 Widerspruchsfrei handeln, Entscheidun-

gen treffen und kommunizieren

2.3.15/2.8.2/3.5.4/3.9

2.02 Persönliche

Integrität und

Verlässlichkeit

2.02.05 Aufgaben sorgfältig erfüllen, um Vertrau-

en bei anderen zu schaffen

3.2/3.3.7/4.2.3

2.03 Persönliche

Kommunikation

2.03.01 Eindeutige und strukturierte Informatio-

nen an andere weitergeben und deren gleiches

Verständnis sicherstellen

2.6.4/3.9/3.10.3

2.03.02 Offene Kommunikation ermöglichen und

fördern

3.3.7/3.9/4.2

2.03.03 Kommunikationsarten und -kanäle aus-

wählen, um die Bedürfnisse der Zielgruppe, der

Situation und der Führungsebene zu erfüllen

2.3.5/2.3.6/3.9

2.03.04 Mit virtuellen Teams effektiv kommuni-

zieren

3.9.8.2/4.1.14.5

2.03.05 Humor und Perspektivenwechsel ange-

messen anwenden

2.3.5/3.3.5/3.3.8/3.5/

3.9.5/3.9.8/3.10.5/4.3.3/

4.3.4/4.4.8/4.4.10

500

Referenzliste zur Individual Competence Baseline (ICB) der IPMA

Tab. 5.1 (Fortsetzung)

Kompetenz

Kompetenzindikatoren

Abschnitt im Buch

2.04 Beziehungen

und Engagement

2.04.01 Persönliche und beruﬂiche Beziehungen

aufbauen und pﬂegen

1.5.2/2.3.6/2.4.10/3.3.8/

3.4/3.10

2.04.02 Soziale Netzwerke aufbauen, moderieren

und an ihnen teilnehmen

1.5.2/1.6.2/4.1.3.3

2.04.03 Durch Zuhören, Verständnis und Unter-

stützung Empathie zeigen

3.9.8

2.04.04 Vertrauen und Respekt zeigen, indem

andere ermutigt werden, ihre Meinungen und

Bedenken zu äußern

1.6.4/3.3.7/3.4/3.7/3.9/

4.1.8/4.1.12.3/4.1.13.3–

4.1.13.9/4.1.14

2.04.05 Eigene Visionen und Ziele kommunizie-

ren, um Engagement und Commitment Dritter zu

erreichen

2.8.1.4/3.7/3.9/4.1.3

2.05 Führung

2.05.01 Initiative ergreifen und proaktiv mit Rat

und Tat zur Seite stehen

3.8/3.9.1/3.9.4/3.10.3/

3.10.4/4.1.2

2.05.02 Ownership übernehmen und Commit-

ment zeigen

4.1.2/4.1.12/4.1.13

2.05.03 Durch Vorgeben der Richtung, durch

Coaching und Mentoring die Arbeit von Einzel-

personen und Teams leiten und verbessern

3.7/3.10.3/3.10.4/4.1.5/

4.1.8/4.1.9

2.05.04 Macht und Einﬂuss angemessen auf Drit-

te ausüben, um die Ziele zu erreichen

2.3.5/2.3.9/4.1.3/4.1.4/

4.1.8/4.1.9

2.05.05 Entscheidungen treffen, durchsetzen und

überprüfen

2.8.2/3.9/4.1.8/4.1.9

2.06 Teamarbeit

2.06.01 Das Team zusammenstellen und entwi-

ckeln

1.5/2.3.9.3/3.1/3.7/4.1.9–

4.1.11/4.1.12.6/4.1.13.3/

4.1.14/4.2

2.06.02 Zusammenarbeit und Netzwerken zwi-

schen Teammitgliedern fördern

1.5/2.3.9.1/3.9.8/4.1.9–

4.1.11/4.2

2.06.03 Die Entwicklung des Teams und der

Teammitglieder ermöglichen, unterstützen und

überprüfen

2.5.5/2.6.6/3.7/3.8/

4.1.12.4/4.2

2.06.04 Teams durch das Delegieren von Aufga-

ben und Verantwortlichkeiten stärken

3.9.7/4.1.5/4.1.8/4.1.14.2

2.06.05 Fehler erkennen, um das Lernen aus

Fehlern zu ermöglichen

2.5.5/2.6.6/3.8.5

Referenzliste zur Individual Competence Baseline (ICB) der IPMA

501

Tab. 5.1 (Fortsetzung)

Kompetenz

Kompetenzindikatoren

Abschnitt im Buch

2.07 Konﬂikte und

Krisen

2.07.01 Konﬂikte und Krisen antizipieren und

wenn möglich verhindern

2.5.5/3.5/4.1.8/4.1.14/4.4

2.07.02 Ursachen und Auswirkungen von Kon-

ﬂikten und Krisen analysieren und angemessene

Reaktionen auswählen

4.4.2/4.4.3/4.4.4/4.4.7–

4.4.9

2.07.03 Konﬂikte und Krisen und/oder deren

Auswirkungen lösen bzw. in ihnen vermitteln

3.3.7/3.9/4.4.6/4.4.10–

4.4.13

2.07.04 Lernergebnisse aus Konﬂikten und

Krisen identiﬁzieren und weitergeben, um die

zukünftige Arbeit zu verbessern

1.5.2/2.5.5/4.2.2/4.2.3/

4.4.12

2.08 Vielseitigkeit

2.08.01 Ein offenes und kreatives Umfeld schaf-

fen und unterstützen

1.5–1.7/2.8.1/3.3.7/4.2.3

2.08.02 Konzeptionelles Denken anwenden, um

Situationen zu analysieren und Lösungsstrategien

zu deﬁnieren

1.3.3/1.6.3/1.6.4/1.7.1–

1.7.3/2.3.15

2.08.03 Analytische Techniken anwenden, um

Situationen, Informationen und Trends zu analy-

sieren

2.3.10/2.3.15/2.8.2

2.08.04 Kreative Techniken fördern und anwen-

den, um Alternativen und Lösungen zu ﬁnden

2.3.16/2.8.1/2.8.2

2.08.05 Ganzheitliche Sicht auf das Projekt und

seinen Kontext fördern, um den Entscheidungs-

prozess zu verbessern

1.3.3/2.3.5/2.3.10

2.09

Verhandlungen

2.09.01 Interessen aller Parteien, die an den Ver-

handlungen beteiligt sind, identiﬁzieren und

analysieren

4.3.1/4.3.2/4.3.3.1/

4.4.10.4

2.09.02 Optionen und Alternativen entwickeln

und evaluieren, die das Potenzial haben, die Be-

dürfnisse aller Beteiligten zu erfüllen

4.3.1/4.3.2/4.3.3.1–

4.3.3.3/4.3.4

2.09.03 Verhandlungsstrategie deﬁnieren, die mit

den eigenen Zielen übereinstimmt und für alle

beteiligten Parteien akzeptabel ist

4.3.3.2/4.3.3.3/4.3.4

2.09.04 Einigungen mit anderen Parteien erzie-

len, die mit den eigenen Zielen übereinstimmen

4.3.3.2/4.3.3.3/4.3.4

2.09.05 Zusätzliche Verkaufs- und Akquisitions-

möglichkeiten entdecken und ausschöpfen

1.2.5/2.3.9.9

502

Referenzliste zur Individual Competence Baseline (ICB) der IPMA

Tab. 5.1 (Fortsetzung)

Kompetenz

Kompetenzindikatoren

Abschnitt im Buch

2.10 Ergebnis-

orientierung

2.10.01 Alle Entscheidungen und Handlungen

hinsichtlich ihrer Auswirkung auf den Projekter-

folg und die Ziele der Organisation evaluieren

2.3.2/2.3.4/2.3.11/2.4.3

2.10.02 Bedürfnisse und Mittel aufeinander

abstimmen, um Ergebnisse und Erfolge zu op-

timieren

2.3.3.4/2.3.5/2.3.11/2.4.3

2.10.03 Gesunde, sichere und produktive Arbeits-

umgebung schaffen und aufrecht erhalten

2.3.9/2.3.11/2.4.3/2.5.2/

4.2

2.10.04 Das Projekt, seine Prozesse und Ergeb-

nisse promoten und „verkaufen“

2.3.5/2.3.6

2.10.05 Ergebnisse liefern und Akzeptanz erhal-

ten

2.5.4/2.5.6.4/4.5

Kompetenzbereich Praktiken (Practice)

3.01 Projektdesign 3.01.01 Erfolgskriterien anerkennen, priorisieren

und überprüfen

2.3.1–2.3.3/2.3.5/2.3.10

3.01.02 Lessons Learned aus und mit anderen

Projekten überprüfen, anwenden und austauschen

2.5.5/2.5.6/2.6.6

3.01.03 Projektkomplexität und ihre Konsequen-

zen für den Projektmanagementansatz bestimmen

1.2.1–1.2.4/1.4/2.1

3.01.04 Generellen Projektmanagement-Ansatz

auswählen und anpassen

1.4/2.1

3.01.05 Konzept für die Projektdurchführung

entwerfen, überwachen und anpassen

1.4/2.1/2.3.13/2.5.4/2.5.6

3.02.01 Hierarchie der Projektziele deﬁnieren

und entwickeln

2.3.2/2.3.3

3.02.02 Bedürfnisse und Anforderungen der Pro-

jekt-Stakeholder identiﬁzieren und analysieren

2.3.3/2.3.5/2.3.11/2.4.2/

2.4.3

3.02

Anforderungen

und Ziele

3.02.03 Anforderungen und Abnahmekriterien

priorisieren und entscheiden

2.3.3/2.3.5/2.3.11/2.4.2/

2.4.3

3.03.01 Lieferobjekte deﬁnieren

2.3.11/2.4.3/2.5.2

3.03.02 Leistungsumfang strukturieren

2.3.11/2.4.3/2.5.2

3.03.03 Arbeitspakete deﬁnieren

2.3.11/2.4.3/2.5.2

3.03

Leistungsumfang

und Lieferobjekte

3.03.04 Konﬁguration des Leistungsumfangs

erstellen und aufrechterhalten

2.3.3/2.3.9/2.3.11/2.4.3/

2.5.2/2.5.6/2.5.7

Referenzliste zur Individual Competence Baseline (ICB) der IPMA

503

Tab. 5.1 (Fortsetzung)

Kompetenz

Kompetenzindikatoren

Abschnitt im Buch

3.04 Ablauf und

Termine

3.04.01 Aktivitäten deﬁnieren, die nötig sind, um

das Projekt (ab)liefern zu können

2.3.11/2.4.7/2.5.2

3.04.02 Arbeitsaufwand und Dauer von Aktivitä-

ten festlegen

2.4.6/2.4.7/2.5.2

3.04.03 Vorgehensweise für Termine und Phasen

respektive Sprints festlegen

2.4.4/2.4.7/2.5.2

3.04.04 Abfolge der Projektaktivitäten bestim-

men und einen Ablauf- und Terminplan erstellen

2.4.4/2.4.7/2.5.2

3.04.05 Fortschritt anhand des Terminplans

überwachen und notwendige Anpassungen vor-

nehmen

2.5.3/2.5.4/2.5.6/2.5.7

3.05 Organisation,

Information und

Dokumentation

3.05.01 Bedürfnisse der Stakeholder bezüglich

Information und Dokumentation beurteilen und

bestimmen

2.3.5/2.3.6/2.4.10

3.05.02 Struktur, Rollen und Verantwortlichkei-

ten im Projekt deﬁnieren

2.3.9/4.1.4/4.1.9–4.1.11

3.05.03 Infrastruktur, Prozesse und Informations-

systeme aufbauen

2.3.5/2.4.10

3.05.04 Organisation des Projekts implementie-

ren, überwachen und ggf. anpassen

2.3.9/4.1.9–4.1.11

3.06 Qualität

3.06.01 Qualitätsmanagementplan für das Projekt

entwickeln, die Implementierung überwachen

und gegebenenfalls überarbeiten

2.4.11

3.06.02 Projekt mit seinen Lieferobjekten

überprüfen um sicherzustellen, dass sie die

Anforderungen des Qualitätsmanagementplans

weiterhin erfüllen

2.4.3/2.4.11/2.5.4/2.5.6/

2.6.3

3.06.03 Erreichung der Qualitätsziele des Pro-

jekts veriﬁzieren und erforderliche korrektive

und/oder präventive Maßnahmen empfehlen

2.4.3/2.5.6/2.5.8/2.6.3

3.06.04 Validierung von Projektergebnissen pla-

nen und organisieren

2.4.11/2.6.3

3.06.05 Qualität im Verlauf des Projekts sicher-

stellen

2.4.11

3.07.01 Projektkosten abschätzen

2.4.4/2.4.6/2.4.9

3.07.02 Projektbudget erstellen

2.4.9

3.07.03 Projektﬁnanzierung sichern

2.2/2.7.1

3.07.04 Finanzmanagement- und Berichtssys-

tem für das Projekt entwickeln, einrichten und

aufrechterhalten

2.5.6/2.5.7/2.7.1.8

3.07 Kosten und

Finanzierung

3.07.05 Finanzen überwachen, um Abweichun-

gen vom Projektplan zu identiﬁzieren und zu

korrigieren

2.5.6/2.5.7/2.7.1.8

504

Referenzliste zur Individual Competence Baseline (ICB) der IPMA

Tab. 5.1 (Fortsetzung)

Kompetenz

Kompetenzindikatoren

Abschnitt im Buch

3.08 Ressourcen

3.08.01 Strategische Ressourcenplanung ent-

wickeln, um die Projektergebnisse liefern zu

können

2.4.8

3.08.02 Qualität und Menge der benötigten Res-

sourcen deﬁnieren

2.4.4/2.4.7

3.08.03 Potenzielle Ressourcenquellen identiﬁ-

zieren und ihre Beschaffung verhandeln

2.4.8/2.9

3.08.04 Ressourcen gemäß dem festgelegten

Bedarf zuweisen und verteilen

2.4.7/2.4.8/2.5.2/4.4

3.08.05 Ressourcenverbrauch evaluieren und

erforderliche Korrekturmaßnahmen ergreifen

2.5.6/2.5.7/3.10

3.09 Beschaffung

3.09.01 Beschaffungsbedarf, Optionen und Pro-

zesse vereinbaren

2.9

3.09.02 Zu Evaluation und Auswahl von Liefe-

ranten und Partnern beitragen

2.9

3.09.03 Zu Verhandlungen und Vereinbarungen

von Vertragsbestimmungen beitragen, um diese

in Einklang mit den Projektzielen zu bringen

2.9/2.3.10.4

3.09.04 Vertragsausführung überwachen,

Probleme ansprechen und falls notwendig Ent-

schädigungen verlangen

2.5.6/2.5.7/2.5.8

3.10 Planung und

Steuerung

3.10.01 Projekt starten, Projektmanagement-Plan

entwickeln und Zustimmung einholen

2.3.5/2.3.10/2.3.12–

2.3.14

3.10.02 Übergang in eine neue Projektphase ein-

leiten und managen

2.2.1/2.2.5/2.3.1/2.3.17/

2.4.1/2.4.12/2.5.1/2.5.9/

2.6.1/2.6.7

3.10.03 Projektleistung mit dem Projektplan

abgleichen und gegebenenfalls Korrekturmaß-

nahmen treffen

2.4.7/2.5.2/2.5.4/2.5.6/

2.5.7

3.10.04 Bericht über den Projektfortschritt erstat-

ten

2.2.5/2.3.17/2.4.12/2.5.4/

2.5.6/2.5.7/2.5.9 2.6.7

3.10.05 Projektänderungen beurteilen, Zustim-

mung für diese einholen und implementieren

2.5.8

3.10.06 Eine Phase oder das Projekt abschließen

und evaluieren

2.2.5/2.3.17/2.4.12/2.5.5/

2.5.9/2.6.6

Referenzliste zur Individual Competence Baseline (ICB) der IPMA

505

Tab. 5.1 (Fortsetzung)

Kompetenz

Kompetenzindikatoren

Abschnitt im Buch

3.11 Chancen und

Risiken

3.11.01 Chancen- und Risikomanagementstruktur

entwickeln und implementieren

2.3.8/2.3.10.2

3.11.02 Chancen und Risiken identiﬁzieren

2.3.8/2.3.10.2

3.11.03 Wahrscheinlichkeit und Auswirkungen

von Chancen und Risiken analysieren

2.3.8/2.3.10.2

3.11.04 Strategien auswählen und Maßnahmen

implementieren, um Chancen und Risiken zu

adressieren

2.3.8

3.11.05 Chancen, Risiken und implementierte

Maßnahmen evaluieren und überwachen

2.3.8

3.12 Stakeholder

3.12.01 Stakeholder identiﬁzieren und ihre Inte-

ressen und ihren Einﬂuss analysieren

2.3.5/2.5.8/3.3.5/4.1.3

3.12.02 Stakeholder-Strategie und Kommunikati-

onsplan entwickeln und aufrechterhalten

2.3.5/2.3.6/2.4

3.12.03 Geschäftsleitung, Auftraggeber und hö-

heres Management einbinden, um Commitment

zu erreichen und um Interessen und Erwartungen

zu managen

2.3.5/4.1.4

3.12.04 Benutzer, Partner und Lieferanten ein-

binden, um Kooperation und Commitment zu

erreichen

2.3.5/2.9

3.12.05 Netzwerke und Allianzen aufbauen, auf-

rechterhalten und beenden

2.3.5/4.1.3.3

3.13 Change und

Transformation

3.13.01 Adaptationsfähigkeit der Organisati-

on(en) zu Veränderung beurteilen

1.4.4/3.5/4.5

3.13.02 Veränderungsanforderungen und Trans-

formationschancen identiﬁzieren

2.3.5/4.5

3.13.03 Veränderungs- oder Transformationsstra-

tegie entwickeln

1.4.4/2.5.5/2.6.6/4.5

3.13.04 Veränderungs- oder Transformations-

management implementieren

2.3.6/2.6.2/2.6.4

Über die Autoren

Jürg Kuster, Dipl.-Ingenieur ETH

Studium der Elektrotechnik an der ETH Zürich. Insgesamt

über elf Jahre als Manager und Projektleiter in verschiedenen

Unternehmen tätig. Ausbilder und Experte für die Schwei-

zerischen Fachprüfungen zum Informatikprojektleiter und

Wirtschaftsinformatiker. Dozent an verschiedenen Ausbil-

dungsinstituten. Inhaber der Pentacon AG in Winterthur und

seit 2008 Geschäftsleiter der BWI Management Weiterbildung

in Zürich.

Arbeitsschwerpunkte: Entwicklung von Führungskräften,

Projekt-Coaching, Konzeption und Einführung von unter-

nehmensweiten Projektmanagement-Standards und Weiterbil-

dungsprogrammen.

www.bwi.ch

Christian Bachmann, Betriebsökonom FH

Studium an FH Aargau und Chur mit Abschluss als Be-

triebsökonom. Weiterbildungen in Coaching, Organisations-

entwicklung und Theologie: Systemische Trainings-Gruppe,

Koenigswieser & Network, Wien; MAS ZFH in Supervision

und Coaching in Organisationen, IAP Zürich; MAS Spirituelle

Theologie in interreligiösen Prozessen, Universität Salzburg.

Zehn Jahre operatives Projektmanagement in der Finanz-

dienstleistungsindustrie. Seit 2006 selbständiger Berater und

Coach und seit 2011 Trainer bei BWI Management Weiterbil-

dung, Zürich.

Arbeitsschwerpunkte: Trainer in Projektmanagement-Methodik, Teamführung, Selbst-

management sowie in der Leitung und Moderation von Sitzungen (in Industrie und in

Bildungsorganisationen). Prozessbegleitungen in der Weiterentwicklung von Projektor-

ganisationen. Coaching von Führungskräften und Projektverantwortlichen.

www.bc-c.ch

507

J. Kuster et al., Handbuch Projektmanagement, https://doi.org/10.1007/978-3-662-57878-0

508

Über die Autoren

Eugen Huber, Dipl. phil. I

Studium an der Université de Neuchâtel. Individualpsycholo-

gischer Berater (Alfred-Adler-Institut Zürich), systemisch-lö-

sungsorientierter Coach (FHNW Olten), Experte in Organisa-

tionsmanagement mit eidgenössischem Diplom, MAS im Lei-

ten & Entwickeln von Bildungsorganisationen (PHLU). Als

neugieriger Mensch mit Begeisterung dem lebenslangen Ler-

nen verpﬂichtet, arrangiert er seit 1972 Lernprozesse auf allen

Stufen. Seit 1987 als Projektleiter, Berater, Coach und Füh-

rungskraft tätig.

Arbeitsschwerpunkte: Projektleitung im Bereich des Public

Management, Berater und Coach für Entwicklungsprozesse von Menschen und Organisa-

tionen, Leitung und Entwicklung von Expertenorganisationen und deren Mitarbeitern.

www.corporate-development.eu

Mike Hubmann, Ingenieur FH, EMBA HSG,

Integral Systemic Coach

Ausbildungen in Coaching, Organisationsentwicklung, syste-

mischer Aufstellungsarbeit, agilem und klassischem Projekt-

management (Certiﬁed Senior Project Manager IPMA Lev-

el B, HERMES 5 Advanced, Certiﬁed Scrum Master), MBA

in Business Engineering, Marketing und Elektrotechnik. Mehr

als 25 Jahre Erfahrung in Projektmanagement von agilen und

klassischen Projekten. Das Meistern anspruchsvoller Projekte

ist seine Kernkompetenz. Seit 2009 Assessor für IPMA Lev-

el B Zertiﬁzierungen beim VZPM und seit 2017 zusätzlich

Prüfungsexperte. Seit 2011 Trainer und Coach der BWI Management Weiterbildung in

Zürich. Seit 2016 Inhaber der Mike Hubmann GmbH.

Arbeitsschwerpunkte: Coach und Organisationsentwickler für Privatpersonen, Teams

und Organisationen in herausfordernden Geschäftssituationen oder in Veränderungssi-

tuationen, Aufsteller (systemische Aufstellungen, Organisationsaufstellungen), Trainer,

Berater, Projektmanager und Projektmanagementexperte.

www.mikehubmann.ch

Über die Autoren

509

Robert Lippmann, Lic. oec. publ., NDU SNU

Kaufmännische Ausbildung, danach Studium und Abschluss

in Wirtschaftswissenschaften (Lic.oec.publ., Uni Zürich)

Weiterbildungen und Diplome in Arbeits- und Organisati-

onspsychologie, Gruppendynamik und Nachdiplom in Unter-

nehmensentwicklung (DNU SNU). Seit 1996 selbständiger

Management- und Organisationsberater, Trainer und Coach

in Industrie, Dienstleistung und Öffentlicher Verwaltung, vor

allem in Projektmanagement, Führung, Coaching, Kommu-

nikation und Moderation. Langjährige Erfahrung als Projekt-

leiter, spezialisiert auf operative Umsetzung von Konzepten,

Organisationsvorhaben und als Bauherrenvertreter. Mitautor des Fachbuchs Lippmann E.

(Hrsg.), Coaching (3. Auﬂ. 2013) im Springer Verlag.

Arbeitsschwerpunkte: Projektleitungen und -Beratungen, Coaching, Trainer in Weiter-

bildungen für Führungskräfte und Projektleiter, Mandate als Manager auf Zeit.

www.lippmann.ch

Emil Schneider, dipl. Ingenieur ETH, Betriebsingenieur

NDS ETH

Abschluss als Elektroingenieur an der ETH Zürich. Weiterbil-

dung in Projektführung, Qualitätsmanagement, Internationales

Industriemanagement, Industrielles Marketing. Nachdiplom-

studium in Betriebswissenschaft am BWI/ETHZ. Zehn Jah-

re Erfahrung als Entwickler und Projektleiter. Fünfzehn Jahre

Führungserfahrung als Leiter von Entwicklungsabteilungen in

großen Unternehmen. Seit 1993 selbständiger Managementbe-

rater, Coach und Trainer (Schneider & Partner).

Arbeitsschwerpunkte: Trainer für Projektmanagement mit

Schwerpunkt Innovation und Coach für Qualität in Unterneh-

mensprozessen.

Patrick Schneider,

dipl. Ingenieur ETH, EMBA Universität Zürich

Studium der Elektrotechnik an der ETH Zürich. Diplomar-

beit an der Harvard University. Executive MBA in General

Management an der Universität Zürich und an der Stanford

University. Fünfzehn Jahre Erfahrung im Business Develop-

ment bei international tätigen Dienstleistern, im e-Commerce

und IT-Outsourcing. Vier Jahre Bereichsleitung auf Stufe Ge-

schäftsleitung mit Produktmanagement, Projektleitung, Test-

abteilung und Kundendienst in der Maschinenindustrie. Seit

2015 aktiv als Trainer für Projektmanagement, als Projektlei-

510

Über die Autoren

ter und als Berater für Projekt-, Produkt- und Prozessmanagement. Gründer und Inhaber

der Schneider Associates. Seit 2016 Mitglied der Geschäftsleitung der BWI Management

Weiterbildung in Zürich.

Arbeitsschwerpunkte: Inhouse Trainings für Produkt- und Projektmanagement; Ein-

führung von Prozessen und Standards; Projektleitungsmandate.

www.schneiderassociates.net

Urs Witschi, dipl. Architekt ETH und Betriebsingenieur

NDS ETH

Studium der Architektur und Nachdiplom in Betriebswissen-

schaft an der ETH Zürich. Weiterbildung in systemischer Be-

ratung. Unternehmensberater an der Stiftung BWI/ETH in den

Bereichen Führung, Organisation und Projektmanagement.

1995 Mitbegründer und Partner des ONION-Netzwerkes und

2002 Mitbegründer und Geschäftsführer der DRIFT Con-

sulting GmbH mit den Schwerpunkten Projektmanagement

und Change-Management. Zwölf Jahre Vorstandsmitglied und

heute Ehrenmitglied der spm (Swiss Project Management As-

sociation). Seit 2017 im Netzwerk www.agil.works als Entwickler und Berater aktiv.

Arbeitsschwerpunkte: Begleitung bei Change-Vorhaben, Coaching von Projektleitern,

Entwicklungsarbeiten und Beratung in Richtung agile Organisation.

www.driftconsult.com

Roger Wüst, dipl. Ingenieur HTL, Betriebsingenieur STV

Studium zum Vermessungs- und Betriebsingenieur. Mehr als

30 Jahre Erfahrung in Ausbildung und Beratung von Füh-

rungspersonen in Privatwirtschaft und Non-Proﬁt-Organisa-

tionen, insbesondere in der Erarbeitung und Implementierung

unternehmensspeziﬁscher

Projektmanagementphilosophien.

Seit 1996 als selbständiger Unternehmer in Privatwirtschaft,

öffentlichen Verwaltungen und an Hochschulen tätig.

Arbeitsschwerpunkte: Coaching von Einzelpersonen und

Teams mit dem Fokus auf Förderung und Entwicklung der

jeweiligen Coachees und Stärkung ihrer Persönlichkeit. Er

bevorzugt dabei wertschätzende Ansätze der Gruppendynamik, systemische Beratungsin-

terventionen und Organisationsaufstellungen.

www.net-coaching.ch

Sachverzeichnis

Ablaufplan, 174

Abnahme, 233

Adjourning, 408

Agile Vorgehensweise, 18

Agiles Manifest, 19

Agiles Projektmanagement, 18, 34, 61, 110,

163, 168, 172, 197, 200, 203, 268, 351,

354, 370

Agiles Vorgehensmodell, 34

Aktives Zuhören, 332

Akzeptanz, 98, 155, 191, 315, 348, 384, 386

Akzeptanzkriterium, 166

Akzeptanzprojekt, 4, 11

Analogiemethode, 260

Änderung, 90, 222

Änderungsantrag, 224

Änderungsmanagement, 223

Anerkennung, 39, 232, 257, 284, 306, 335, 405,

408, 423, 432, 469

Anforderung, 80, 83, 86, 482

Funktionale Anforderung, 88

Nicht-Funktionale Anforderung, 88

Priorisierung von Anforderungen, 88

Rahmenbedingung, 88

Anforderungskatalog, 83, 159, 170

Angst, 298

Arbeit am System, 39, 44, 46, 313, 360, 375,

398, 405

Beziehung, 39

Organisation, 39

Arbeit im System, 38, 46, 359, 375, 398, 404,

407

Inhalt, 38

Arbeitspaket, 138, 141, 147, 174, 465

Arbeitstechnik, 311

Audit, 192, 216

Aufgabe, 113, 116, 361

des Auftraggebers, 113, 116

des Auftraggebers / Projektausschusses, 210

des Product Owner, 113

des Projektausschusses, 113, 116

des Projektleiters, 117, 210

des Scrum Master, 113

Aufgabenpaket, 141

Aufgabe-Kompetenz-Verantwortung, 357

Aufstellung, 364, 400

Auftraggeber, 19, 111, 113, 116, 227, 358, 377,

386, 463

Auftragsabwicklungsprojekt, 11

Auftragsklärung, 130

Aufwandschätzung, 170, 173, 174, 217, 312

Auslastung, 186

Ausscheidekriterium, 85, 266

Ausschreibung, 270

Auswirkungsanalyse, 227

Authentizität, 367

autoritärer Führungsstil, 380

Autorität, 350, 355

A-K-V, 357

Axiomtheorie, 319

Backlog

Product Backlog, 163

Sprint Backlog, 197

Balkenplan, 175

BATNA-Prinzip, 421, 463

Bedeutsamkeit, 307

Bedürfnisse, 155

Begleitgruppe, 116

Belbin, 40, 337, 388

511

512

Sachverzeichnis

Belbin Blinder Fleck, 389

Belbin Teambericht, 388

Belbin Teamrolle, 336, 337, 372, 388, 467, 469

Belbin Teamrollenbericht, 339

Bemächtigung, 350

Benutzerschulung, 234

Benutzer-Handbuch, 234

Berichtswesen, 191, 206, 208

Beschaffung, 268

Best-in-Market, 93

Betriebsorganisation, 235

Betriebsprozess, 235

Betriebsübergabe, 235

Bewältigungsstrategie, 297

Bewertungskonﬂikt, 436, 465

Bewusstsein, 289

Beziehung, 350

Beziehungskonﬂikt, 439, 468

Bionik, 259

Blinder Fleck, 327

Blinder Fleck im Team, 389

Botschaft

Ich- und Du Botschaft, 325

Komplettbotschaft, 321

Brainstorming, 257

Break-even Analyse, 183, 222

Burndown Bericht, 200

Burndown Chart, 200, 407

Burnout, 300

Business Case, 69, 72, 158

Change, 476

Change Request, 91

Change Request Antrag, 224

Change Request Management, 223

Change-Projekte, 29

Circle of Competence, 310

Claim Management, 223, 227, 415

Coaching, 332, 340, 360

Collaboration-Tools, 191

Compliance, 134

Concurrent Engineering, 32

Controlling, 117, 204, 248, 407, 419

Critical Thinking Appraisal, 338

Cyneﬁn-Framework, 35

Daily Standup / Daily Scrum, 64, 168, 200, 405

Daily Standup/Daily Scrum, 288

Datenschutz, 135

Deﬁnition of Done, 166

Delegation, 361

delegativer Führungsstil, 380

Deliverable, 144

Delphi Methode, 173

Deming-Kreis, 154

Design Thinking, 154, 155

Design-to-Cost, 93, 182

Detailplanung

Ablaufplan, 65

Kostenplan, 65

Ressourcenplan, 65

Terminplan, 65

Detailziel, 83

Deutsche Gesellschaft für Projektmanagement,

Dialogverfahren, 268

Dilemma, 297, 308, 386, 437, 467

DIN 69901, 58

DMAEC, 154

DMAIC, 154

Dokumentation, 189

Downside-Strategie, 343

Du-Botschaft, 325

Dynamik in Teams, 403

Adjourning, 408

Forming, 403

Norming, 405

Performing, 407

Storming, 404

Dynamische Payback-Methode, 222

Earned-Value-Analyse, 207

Ebenen der Zusammenarbeit, 38, 40, 97, 341,

425

Eignungskriterien, 273

Einﬂuss-Organisation, 120

Einführungsarten, 232

Einführungsphase, 27, 229

Einladungsverfahren, 272

Einmalkosten, 183, 221

Einstellung, 397

End-Review, 217

Entscheidungsﬁndung, 72, 262, 340

Entwicklungsprojekt, 11

Epic, 166

Sachverzeichnis

513

Erfolgsfaktor, 76, 250

Erfolgsfaktoren der Zusammenarbeit, 337

Ergebniskontrolle, 249

Ermächtigung, 350, 365

Ersatzbefriedigung, 443

Eskalationsstufe, 447

e-learning, 234

Existenzangst, 480

Expertenschätzung, 173

Extreme Programming, 19

extrinsische Motivation, 305

Eye of Competence, 13, 53, 495

Fachkompetenz, 276

Fachspezialist, 385

Fail fast, 318

Failure Mode and Effect Analysis, 106

Feasibility Study, 99

Feedback, 156, 325, 326

Feedbackregeln, 328

Fehlermöglichkeit- und Einﬂussanalyse, 106

Fischgräten-Methode, 132

Flow, 302

FMEA, 104

Design FMEA, 106

Konzept FMEA, 106

Produkt FMEA, 106

Produktions-FMEA, 106

Prozess FMEA, 106

System FMEA, 106

Formel der Veränderung, 480

Forming, 403

Fortschrittskontrolle, 249

Frage

Aktives Zuhören, 332

geschlossene Frage, 330

Herzfrage, 334

hypothetische Frage, 334

offene Frage, 330

ressourcenorientierte Frage, 334

Skala Frage, 334

zielorientierte Frage, 334

zirkuläre Frage, 334

Fragetechnik, 330

Freihändige Vergabe, 272

Fremdeinschätzung, 339

Fremdsteuerung, 42, 44, 45, 305

Frustrationstoleranz, 474

Führung, 349, 373, 378, 469

Ausprägungen von Führung, 359

indirekte Führung, 374

laterale Führung, 381

Führungsarbeit, 360

Führungsaufgabe, 110

Führungskompetenz, 111, 116, 275, 349, 350,

356, 398

Führungskontinuum, 127

Führungsmodell

situatives Führungsmodell, 380

Führungsstil, 378

autoritärer Führungsstil, 380

delegativer Führungsstil, 380

integrierender Führungsstil, 380

partizipativer Führungsstil, 380

Gantt-Diagramm, 175

Gate Review, 217

Geborgenheit, 283, 432

Gebrauchsanleitung, 234

Gehirn, 263, 279, 287

Gehorsam

vorauseilender Gehorsam, 359, 427

gelebte Rolle, 367, 466

Generation Y, 285

Gesamtprojekt, 140

Gestaltungswille, 483

Globalziel, 82

Golden Proﬁler of Personality, 336

Governance, 134

GPM, 52

GPOP, 340

Gremium, 109, 111, 113, 116, 129, 237, 322,

351, 356, 361, 437

Grobplanung, 137, 168, 179

Grobziel, 82

Grooming, 165, 203

Grundbedürfnis, 282

Grundemotion, 432

Grundhaltung, 315

HACCP, 104

Haltung, 397

Handlungsfähigkeit, 309

Harmonie, 387

Harvard-Konzept, 416, 419, 459

514

Sachverzeichnis

Heißer Konﬂikt, 442

HERMES, 51, 57, 84

Humor, 292

Hybride Vorgehensweise, 28

Hybrides Projektmanagement, 28, 34, 61, 118

Hybrides Vorgehensmodell, 34

ICB, 52, 495

Ich-Botschaft, 325

Ideenmanagement, 261

Inbetriebnahme, 233

Individual Competence Baseline, 52, 495

Information, 189

Informationssicherheit, 135

Informationssystem, 191

Initialisierungsphase, 24, 74

Inkrement, 21, 198, 203

Innovationsprojekt, 11

integrierender Führungsstil, 380

Integrität, 15, 47, 135, 283

Interessenkonﬂikt, 433, 464

International Project Management Association,

Intervision, 342

intrinsische Motivation, 305

INVEST Merkmale, 166

IPMA, 52

IPMA Zertiﬁzierung, 495

Ishikawa-Diagramm, 133

ISO 21500, 58

Johari-Fenster, 326

Kalter Konﬂikt, 442

Kanban, 19, 22, 177

Kanban Board, 28, 199

Kano-Modell, 89

Kapazitätstreue Planung, 181

Kapitalwert-Methode, 222

KEF, 76

Kepner-Tregoe, 154

Key Performance Indikator, 79

Kick-off, 149

Klassische Vorgehensweise, 22

Klassisches Projektmanagement, 18, 22, 34, 61,

110, 115, 159, 170, 174, 184, 192, 204,

222, 270, 351, 353, 377

Klassisches Vorgehensmodell, 34

Kleinprojekt, 11

Kohärenz, 307

Kohäsion, 406

Kollegiale Führung, 373, 394

Kommunikation, 189, 318, 468

Persönliche Kommunikation, 318

Kommunikationskonzept, 11, 39, 96, 161, 191

Kommunikationskreislauf, 322

Kommunikationsmatrix, 191

Kommunikationsquadrat, 319

Appell, 320

Beziehung, 320

Inhalt, 319

Selbstoffenbarung, 320

Kommunikationssystem, 191

Kompass, 64

Kompetenz, 110

Fachkompetenz, 276

Führungskompetenz, 275

Methodenkompetenz, 275

Selbstkompetenz, 275

Teamkompetenz, 275

Verhandlungskompetenz, 275

Kompetenzbereich, 14

Kontext, 14

Mensch, 14

Praktiken, 15

Kompetenzkreis, 310

Kompetenzmodell, 275, 371, 377

Kompetenzproﬁl

im agilen Projekt, 371

im klassischen Projekt, 377

Kompetenzregelung, 125

Komplettbotschaft, 321

Komplexität, 4, 366

Konﬁguration des Portfolios, 242

Konﬂikt, 231, 422

Annäherungs-Annäherungskonﬂikt, 437

Annäherungs-Vermeidungskonﬂikt, 439

Bewertungskonﬂikt, 436, 465

Beziehungskonﬂikt, 439, 468

Grundemotion, 432

Harvard-Konzept, 459

heißer Konﬂikt, 442

Interessenkonﬂikt, 433, 464

kalter Konﬂikt, 442

latenter Konﬂikt, 442

offener Konﬂikt, 442

Sachverzeichnis

515

organisatorischer Konﬂikt, 435, 465

persönlicher Konﬂikt, 437, 467

Ressourcenkonﬂikt, 435, 464

Rollenkonﬂikt, 436, 466

Schichtenmodell, 449

sozialer Konﬂikt, 439, 468

struktureller Konﬂikt, 435, 465

Vermeidungs-Vermeidungskonﬂikt, 438

verschobener Konﬂikt, 443

Verteilungskonﬂikt, 435, 464

Wertekonﬂikt, 441, 470

Zielkonﬂikt, 433, 463

Konﬂiktart, 433

Konﬂiktbewältigung, 422, 454, 459, 463, 472

Konﬂiktdiagnose, 441, 447

Konﬂiktfähigkeit, 473

Konﬂiktmanagement, 422

Konﬂiktpotenzial, 429

Konﬂiktprävention, 472

Konﬂiktstil, 444

Konﬂiktsymptom, 429

Konﬂiktsyndrom, 427

Konﬂikt-Eskalationsstufe, 447

Konfrontation, 414, 444

Können, 281

Konsensfähigkeit, 348

Kontext, 14

Kontextanalyse, 130

Konzeptphase, 26, 159

Kooperationsbereitschaft, 483

kooperative Konﬂiktbewältigung, 455

Kostenkontrolle, 218

Kostenkurve, 188

Kostenplan, 65, 187

Kostentransparenz, 221

Kostenwirksamkeitsanalyse, 262

KPI, 79

Kreativität, 47, 255

Domäne, 48

Feld, 48

Mensch, 48

Kreativitätstechnik, 47, 87, 156, 255

Krise, 474

Kritischer Erfolgsfaktor, 76

Kritischer Pfad, 176

Kultur, 293

Large Scale Scrum (LeSS), 19

Lastenheft, 83, 170

laterale Führung, 381

Leadership, 374

Lean, 154

Lebenswelt, 335

Leistungs

bereitschaft, 276

fähigkeit, 276

möglichkeit, 277

Lenkungsausschuss, 116

Lernangst, 480

LeSS, 19

Lieferobjekt, 64, 138, 142, 144, 147, 174, 233,

465

Life-Cycle-Kosten, 183, 221

Linienorganisation, 108

Lose/Lose, 448

Lösung herstellen, 260

Lösungsauswahl, 255, 265

Lösungsbewertung, 262

Lösungsﬁndung, 255

Lösungskonzept, 159, 170

Lösungsorientierung, 315

Lösungssuche, 261

Lösungstest, 260

Lösungsvariante, 159

Machbarkeitsstudie, 99

Macht, 350

geliehene Macht, 353

institutionelle Macht, 352

persönliche Macht, 352

Machtquellen, 351

Magisches Dreieck, 81, 92

Kosten, 92

Scope, 92

Zeit, 92

Management by Objectives, 383

Matrix-Projektorganisation, 123, 356

MbO, 383

MBTI, 40, 340

Mechanistisches Weltbild, 45

Mehrfachrolle, 129

Meilenstein, 64

Meilenstein Review, 217

Meilensteinplan, 137, 138

Meilenstein-Trendanalyse, 207

Mensch, 14, 278

516

Sachverzeichnis

Metamirror, 421, 461

Meta-Kommunikation, 323

Methodenkompetenz, 111, 118, 275, 492

Mind Change, 478

Mindset, 393

Monochrone Organisationskultur, 395

Morphologischer Kasten, 262

MoSCoW-Priorisierung, 90

Motivation, 277, 304

extrinsische Motivation, 305

intrinsische Motivation, 305

Multikulturelle Zusammenarbeit, 394

Multiplikatoren Methode, 173

Multiprojektmanagement, 58, 185, 239, 464

Aufgabenfeld, 240

Element, 240

Problemfeld, 240

Reporting im Multiprojektmanagement, 248

Multiprojektstruktur, 247

Mündliche Kommunikation, 191

Mussziel, 85

Nachforderungsmanagement, 223, 227

Nachkontrolle, 217

Neuroplastizität, 279

Nicht-triviales System, 42

Nichtziel, 82

Norming, 405

Nullserie, 233

Nutzwertanalyse, 262

Offenes Verfahren, 272

Optimierungskriterium, 85, 265, 266

Organisationsaufstellung, 400

Organisationsform, 8

Matrix-Projektorganisation, 123

Projektkoordination, 120

reine Projektorganisation, 121

Organisationskultur, 293

monochrone Organisationskultur, 395

polychrone Organisationskultur, 395

Organisationsrahmen, 381

Organisatorischer Konﬂikt, 435, 465

Orientierung, 307

partizipativer Führungsstil, 380

Passung, 307

PDCA-Zyklus, 154

People, 14

Performing, 407

Persönliche Kommunikation, 318

Persönlicher Konﬂikt, 437, 467

Persönlicher Rahmen, 381

Persönlichkeitstypologie, 336

Perspective, 14

PERT, 173

Pﬂichtenheft, 159, 170

Phase

Einführungsphase, 27, 229

Initialisierungsphase, 24, 74

Konzeptphase, 26, 159

Projektbeauftragungsphase, 24, 69

Realisierungsphase, 26, 195

Phasenbericht, 161

Phasenkonzept, 22

Phasenplan, 138, 205, 254

Pilotversuch, 233

Pink Zone, 392

Pionierprojekt, 6, 11

Plan/Ist-Kostenvergleich, 188

Planhorizont, 135

Planning Poker, 172

Planung, 137, 168, 178

Planungsstil, 395

Plus-Minus-Liste, 227

PMA, 52

PMBOK® Guide, 53

PMI, 53

PMO, 252

Polarität, 398

Polychrone Organisationskultur, 395

Portfolio, 248

Portfolioboard, 72, 206, 242

Portfoliomanagement, 191, 239, 250, 254, 495

Portfoliomanager, 52

Portfoliomix, 239

Portfolioplanung, 72

Portfolio-Konﬁguration, 242

Position, 364

Potentialprojekt, 5

power user, 234

Practice, 15

Präferenzmatrixverfahren, 267

Praktiken, 15

Prävention, 472

Sachverzeichnis

517

Praxisbeispiel, 66

PRINCE2, 54

Prioritätsklassiﬁzierung, 244

Problemlösungsprozess, 152

Problemlösungszyklus, 152

Product Backlog, 21, 61, 82, 87, 88, 113, 159,

163, 168, 171, 197, 198, 200, 222, 231,

235, 268, 376, 475

Product Owner, 21, 110, 111, 113, 163, 169,

309, 370, 371, 409, 463, 476

Produktivsetzung, 233

Produktkonzept, 21, 78, 82, 159, 163, 475

Produktmanagement, 13

Produktvision, 39, 61, 163

Programmmanagement, 12, 58, 250, 495

Programmmanager, 52

Project Management Institute, 53

Project Management Ofﬁce, 252

Projekt Management Austria, 52

Projektabschluss, 236

Projektänderung, 222

Projektantrag, 26, 69, 71, 73, 222

Projektart, 6

Projektauftrag, 26, 39, 43, 73, 74, 82, 84, 114,

116, 129, 145, 162, 215, 309, 352, 358,

359, 361, 377, 386, 409, 436, 463, 464

Projektausprägung, 4, 387

Akzeptanzprojekt, 4

Pionierprojekt, 6

Potentialprojekt, 5

Standardprojekt, 4

Projektausschuss, 85, 111, 115, 116, 206, 209,

210, 217, 373, 375, 386, 436, 437

im agilen Projekt, 113

im klassischen Projekt, 116

Projektbeauftragungsphase, 24, 69

Projektbeurteilung, 215

Projektcharakter, 4

Projektcontrolling, 27, 204

Projektdirektor, 52

Projektdokumentation, 191

Projekthandbuch, 149

Projektion, 469

Projektklasse, 9

Projektkontrolle, 206

Projektkoordination, 120, 356

Projektkoordinator, 385

Projektkultur, 391

Projektleiter, 52, 110, 111, 117, 358, 385, 409,

476

Projektliste, 243

Projektmanagement, 12

agiles Projektmanagement, 18, 34, 61,

110, 163, 168, 172, 197, 200, 203,

268, 351, 354, 370

Dimensionen im Projektmanagement, 13

hybrides Projektmanagement, 28, 34, 61,

118

klassisches Projektmanagement, 22, 34,

61, 353, 377

Projektmanagementhandbuch, 254

Projektmanagementkompass, 64

Projektmanagementmethodik, 472

Projektmanagementplan, 149

Projektmanagementrichtlinie, 254

Projektmanagementstandards, 51

Projektmarketing, 97, 191

Projektmitarbeiter, 52

Projektorgan, 110

Projektorganisation, 108, 110, 115

Projektphase, 64

Projektplanung, 137, 168, 178

Projektportfolio, 13, 43, 53, 58, 69, 74, 105,

239, 242, 248, 250, 253, 365, 435, 464,

467, 482

Projektpriorität, 243

Projektrückschau, 236

Projektschlussbeurteilung, 236

Projektsteckbrief, 24, 69, 72

Projektsteuerung, 210

Projektstrategie, 93

Projektstrukturierung, 137

Projektstrukturplan, 64, 137, 142

Projektteam, 111, 117, 385

Projektteamzusammensetzung, 386

Projektwürdigkeit, 8

Projektziel, 80

Prototyping, 32, 156

Prozentsatzmethode, 173

Prüfen, 192

PSP, 142

Psychologik, 482

Psychometrische Verfahren, 337

Puffer, 176

Qualität der Beziehung, 322

518

Sachverzeichnis

Qualitätsmanagement, 192

Qualitätsmanagementplan, 193

Quality Gate Review, 217

RACI Matrix, 125, 425, 465

Radical Collaboration, 392

Rahmenbedingung, 84, 88, 266

Rangordnung, 469

Rangreihenverfahren, 267

Realisierungsphase, 26, 195

Rechtsvorschriften, 134

Reﬁnement, 165, 203

Reine Projektorganisation, 121, 356

Reiss Motivation Proﬁle, 337

Releaseplan, 61, 159, 168, 475

Releaseplanung, 168

Rentabilitätsrechnung, 222

Reporting, 206, 208, 361

Reporting im Multiprojektmanagement, 248

Request for Information, 271

Request for Proposal, 271

Request for Quotation, 271

Requirements Engineering, 87

Reserven, 174

Resilienz, 313

Ressourcenabhängigkeit, 247

Ressourcenabstimmung, 184

Ressourceneinsatzplan, 184

Ressourcenhistogramm, 181

Ressourcenkonﬂikt, 435, 464

Ressourcenkontrolle, 220

Ressourcenverfügbarkeit, 247

Retrospektive, 203, 232

Return on Investment, 222

Revier, 468

Review, 128, 139, 192, 216, 232, 249

Reviewboard, 116

RFI, 271

RFP, 271

RFQ, 271

Risiko, 101

Risikoliste, 104

Risikomanagement, 100, 318

Risikomanagementtool, 104

Risikoprozess, 100

Risk Impact, 224

ROI, 222

Rolle, 109, 111, 113, 116, 356, 364, 367, 437

gelebte Rolle, 367, 466

Rollenkonﬂikt, 436, 466

Rollensender, 367

Rollenträger, 367

Rollenübernahme, 368, 437

Rückwärtsterminierung, 182

Sachlogik, 482

SAFe, 19

Scaled Agile Framework (SAFe®), 19

Schätzgenauigkeit, 65, 177

Schätzung, 65

Scheitern, 316

Schichtenmodell, 449

Schlupf, 176

Schlüsselposition, 385

Schulz von Thun, 319, 332

Schutzbedarfsanalyse, 135

Schwerpunktthema, 166

Scope, 20, 38, 87, 92, 147, 170, 227, 253, 409,

422, 482

Scope Creeping, 426

Scrum, 20, 61, 163, 168, 197, 200, 203, 370

Scrum Alliance, 52, 57

Scrum Master, 21, 44, 111, 113, 198, 200, 203,

309, 351, 361, 368, 370, 371, 408, 436,

465, 476

Selbsteinschätzung, 339

Selbstentfaltung, 284

Selbsterkenntnis, 336, 337

Selbstkompetenz, 111, 115, 275

Selbstmanagement, 308

Selbstorganisation, 22, 45, 111, 195, 371

Selbstreﬂexion, 289, 431

Selbststeuerung, 42, 45, 46, 114, 350, 372,

375, 394, 399, 431, 436, 454

Selektive Wahrnehmung, 288, 322

Selektives Verfahren, 272

Serienproduktion, 229

Simultaneous Engineering, 32

Sinn, 306

Situationsanalyse, 130

situatives Führungsmodell, 380

Six Sigma, 154

Slack, 176

SMART, 85

Sounding Board, 116

sozialer Konﬂikt, 439, 468

Sachverzeichnis

519

sozialer Status, 284

Sozialkompetenz, 111, 116, 276, 371, 378

Speziﬁkation, 83

Spiralmodell, 34

Sprint Backlog, 197, 199, 200

Sprint Planung, 168, 197, 199

Sprint Review, 21, 113, 203, 351, 407

Sprintdurchführung, 200

Stacey-Matrix, 35

Stage Gate Review, 217

Stakeholder, 155

Stakeholder-Analyse, 94

Stakeholder-Management, 93

Stammorganisation, 58, 108, 119, 278, 347,

351, 356, 358, 365, 410, 434, 435, 465,

469

Standardprojekt, 4

Steering Committee

im agilen Projekt, 113

im klassischen Projekt, 116

Steuergruppe, 116

Storming, 404

Störung, 473

Story Points, 172

Strategieumsetzung, 250

Stress, 295

Stressor, 299

Stressreaktion, 298

Struktureller Konﬂikt, 435, 465

Swiss ICB, 495

SWOT-Analyse, 131

SWOT-Strategie, 132

Synektik, 259

Systemischer Ansatz, 43

Systemisches Phänomen, 424

Systemisches Weltbild, 45

Systemziel, 83, 142, 363

Szenario-Technik, 135

Target Costing, 182

Task, 142

Task Force, 122

Tätigkeit, 142

Tätigkeitsliste, 175

Taylorismus, 1, 41, 275

Team, 114, 347, 370

im agilen Projekt, 370

im klassischen Projekt, 377

Teamarbeit, 38

Teambericht, 388

Teamkapazität, 198

Teamkompetenz, 111, 116, 275

Teammitarbeiter, 385

Teamrahmen, 382

Teamrolle, 196, 336, 337, 388, 467, 469

Teamrollenbericht, 339

Teilprojekt, 137, 140

Teilprojektleiter, 117

Teilziel, 84

Terminkontrolle, 218

Terminplan, 174

Termintreue Planung, 181

Testen, 193

Timebox, 21

Time-to-Market, 93

train-the-trainer, 234

Transformation, 476

Tripple constraint, 93

Triviales System, 42

Tuckman, 403

T-Shirt Sizing, 172

Umfeldanalyse, 130, 210

Umweltanalyse, 130

Ungehorsam

konstruktiver Ungehorsam, 358

Upside-Strategie, 343

Ursachen-Wirkungsanalyse, 132

User Story, 166

Variantenbildung, 261

Veränderung, 29, 295, 476

Veränderungsbereitschaft, 481

Veränderungsprozess-Modell, 484

Verantwortlichkeit, 125

Verbesserungsvorschlag, 11, 203

Verein zur Zertiﬁzierung von Personen im

Management, 52

Verhandlung, 15, 80, 92, 185, 274, 359, 409,

459, 491

Harvard-Konzept, 419

Verhandlungsführung, 399, 409, 417

Verhandlungskompetenz, 111, 116, 275

Verhandlungsstrategie, 413, 416, 419

Verhandlungstaktik, 416

520

Sachverzeichnis

Verhandlungsverfahren, 272

Verhandlungszyklus, 410

Verschobener Konﬂikt, 443

Versionenkonzept, 33

Verteilungskonﬂikt, 435, 464

Vertragsentwurf, 273

Vertrauen, 30, 190, 290, 328, 354, 363, 366,

374, 397, 406, 418, 455, 458, 473

Vielseitigkeit, 47

Virtuelles Team, 399

vorauseilender Gehorsam, 359, 427

Vorbereitung Betrieb, 235

Vorgehensmodell

agil, 34

hybrid, 34

klassisch, 34

Vorgehensprinzip, 16

Phasengliederung, 137

Problemlösungsprozess, 152

Variantenbildung, 18

vom Groben zum Detail, 16

Vorgehensziel, 83, 363

Vorwärtsterminierung, 181

VUKA-Welt, 286, 485

V-Modell, 31

VZPM, 52

Wahrnehmung, 287

Wasserfall-Modell, 18

WBS, 142

Wechselwirkung, 40, 45, 278, 409, 442, 492

Weltbild

mechanistisch, 44

systemisch, 44

Wertekonﬂikt, 441, 470

Wert-Risiko-Matrix, 91

Widerstand, 3, 30, 197, 231, 429, 430, 444,

476, 481, 486

Formen von Widerstand, 488

Intervention bei Widerstand, 492

Umgang mit Widerstand, 489

Win/Lose, 448

Win/Win, 447

wirtschaftliche Projektsituation, 221

Wirtschaftlichkeit, 73, 100, 117, 158, 183, 194,

215, 222, 236, 244, 478

Wissen, 281

Work Breakdown Structure, 142

Workplace Big Five, 337

WPB5, 337

Wunschziel, 85

Zeitmanagement, 311

Zeitmanagement-Matrix, 312

Zertiﬁzierung, 495

Zertiﬁzierungsmodell, 51

Ziel, 3, 80, 129, 135, 142, 170, 210, 215, 223,

230, 252, 377, 383, 404, 429, 464, 474,

482

Detailziel, 83

Globalziel, 82

Grobziel, 82

Mussziel, 85, 266

Nichtziel, 82

Optimierungsziel, 85

SMARTes Ziel, 85, 421, 463

Sollziel, 85

Systemziel, 83, 142

Vorgehensziel, 83

widersprüchliche Ziele, 85

Wunschziel, 85, 266

Zieländerung, 90

Zielformulierung, 84

Zielkonﬂikt, 433, 463

Zielpyramide, 412

Zielsetzung, 80

Zielvereinbarung, 384

Zielvorgabe, 384

Zugehörigkeit, 307

Zusammenarbeit, 1, 2, 25, 27, 38, 41, 45, 347,

388

Ebenen der Zusammenarbeit, 38, 40, 97,

341, 425

Zuschlagskriterien, 273

Zuwendung, 283, 432

Zwei Ebenen der Veränderung, 478